Today is a good day to code

IIS 6 Application Pools

Posted: December 31st, 1969 | Author: | Filed under: Uncategorized | No Comments »

IIS 6 Application Pools

Picture of IrvinI've been slaving over the past few weeks over the weirdness that is IIS 6. Microsoft has been doing some really cool stuff with IIS 6, however frequently it seems like IIS 6 is too smart for its own good.

The default settings for IIS 6 work really well for most standard medium-traffic websites, but for high-traffic sites, or the GIS type services I have been working with were each request takes a second to process, and uses all of the available system resources I have been seeing a lot of 503 errors. The biggest problem with this, other than the fact that the client doesn't get what its expecting, is that browsers don't really know how to handle the error. Either they will give you a “Service Unavailable” error, or it will just say “the page cannot be displayed” if the application pool is disabled due to the “rapid-fail protection.” Its this rapid failure protection that is one problem, and its settings will almost always need to be changed from the default.

The other problem with the default settings is that the 4000 request limit on the kernel is easily surpassed. If you have only a single worker, its 4000 request queue length will get your pool disabled. Increasing this is usually going to be a good idea depending on your situation. Requests that come in after that 4000 worker queue will get a 503 error.

It also might be a good idea to use more worker processes, although I haven't seen a direct increase in the performance of the application with adding more worker processes. Sometimes I've seen a slight decrease in the performance due to the extra load on the server in spawning and managing all the workers. This is a direct imitation of Apache 1.3 and probably Apache 2.0, although I haven't spent much time with Apache 2.0, as this is the way it handles new requests. The problem is that the implementation is clearly young. If a worker fails to respond, the OS throttles the worker and refuses any additional requests until the queue has been exhausted, at which time it kills of that worker and spawns another. When you are at the default 1 worker per pool, you can see where this would cause problems with overall server performance under load.

As always this information is buried deep within Microsoft's site, as far as what worker processes are and how they work. They should probably have spent a little more time with the configuration screen and had something more similar to IIS 5's optmization tab that had options for “fewer than 100,000 requests,” “about 100,000 requests,” and “greater than 100,000 requests.” It would have saved this developer a bunch of time scouring the code and the server configurations.