Request a topic or
contact an Arke consultant
404-812-3123
September 2009

Arke Systems Blog

Useful technical and business information straight from Arke.

About the author

Author Name is someone.
E-mail me Send mail

Recent comments

Archive

Authors

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

IIS 6 Compression Review

There’s a lot of information out there on IIS compression.  Especially for what seems like it should be a simple topic…

Here are a few things I haven’t seen collected well in one spot:

1) Don’t test your compression settings from behind ISA.  Two reasons: ISA can strip the accept compression header to allow it to inspect content, and some of the default IIS settings are to not compress for web proxies (apparently some web proxies have trouble with compression).

2) There are two sources of troubles with compression:

  • Proxies serving compressed content to web browsers that don’t support compression.  There are two ways to address this in IIS 6: Either don’t serve compressed content to proxies by setting HcNoCompressionForProxies to true, or else set HcSendCacheHeaders to true and use the default in-the-past HcExpiresHeader & HcCacheControlHeader values so that proxies will consider the file expired and not cache it.
  • Web browsers that claim to support compression but don’t support it properly.  The most common one still in use is some versions of IIS 6 (see for example http://support.microsoft.com/kb/825057 ).  A good list of compression compatability issues is at http://schroepl.net/projekte/mod_gzip/browser.htm .  The safest thing to do is to not serve compressed to IE6.  Unfortunately, there is no simple way to do this in IIS 6.   (the Microsoft Ajax library automatically does this for its files if you use its compression). 

3) If you are using Microsoft’s AJAX (ScriptResource.axd) it can do compression separately from IIS, but if you have both do compression you will break things.  So either configure IIS to NOT compress AXD and set the scriptResourceHandler enableCompression="true" flag, or else configure IIS to compress AXD and set scriptResourceHandler enableCompression to false.  Note that you may have problems with other AXD files depending on what sort of content they produce.


Posted by David Eison on Tuesday, September 1, 2009 5:28 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Log4net and web gardens

If you actually want to use more than 1 processor for a website on your fancy multi-processor server (IIS calls this a “web garden” because marketers like to brand new terms for existing technologies), and you’re using a log4net file appender, a default configuration will cause problems for you as your separate web server processes run into locks on the same log file.  To avoid this, you’ll need to configure log4net to put the PID in the filename:

e.g.

<appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">

. . .

<file type="log4net.Util.PatternString" value="C:\\IISLogs\\project\\log.pid.%processid.d" />

. . .

<datePattern value="yyyyMMdd'.txt'" />

Unfortunately, this ruins easy filename based date sorting. Don’t know how to do anything about that.

I recommend avoiding the ‘MinimalLock’ configuration that you will see mentioned in google searches. It opens and closes the file for every log message; while I haven’t tested this specifically with log4net, I have run into several apps in the past that ruined their performance by excessive file opening and seeking.


Posted by David Eison on Tuesday, September 1, 2009 4:40 PM
Permalink | Comments (0) | Post RSSRSS comment feed