Webhosting Performance Tunings For IIS7

In a webhosting environment you have hundreds of web sites on a single server. Each web site may not see a significant traffic but when you combine the traffic to all the sites on the server it is quite significant and so it is necessary to tune the server for a webhosting environment.

Here are a few performance related tunings that you can make to help performance and host more sites on your IIS7 server:

1. Make sure your server is running a 64-bit operating system(OS) thus allowing the OS to address more than 4GB of virtual address space. Run your application pools as SysWow64 aka 32-bit on 64-bit windows OS. The advantage in running as SysWow64 is that when compared to the native 64-bit the worker process is light weight – lower memory foot print - allowing more number of worker processes to run at any given time.

2. Perhaps the most important feature for web hosting environment is the new dynamicIdleThreshold feature in IIS7. In a web hosting environment you can divide all active(running) sites on a web server into two categories: hot and cold. Hot sites are the ones which are frequently visited while the cold ones see very low traffic. When hundreds of worker processes are spawned to serve these sites, available memory on the system starts running thin. At one point the system will run out of memory and the performance of the running active sites will suffer. Furthermore, new requests to new sites will not be honored. The dynamicIdleThreshold feature allows you to work around this problem. This feature keeps track of how much memory is being used on the system, and if it reaches a particular set threshold, it cuts down the idle timeout for the application pools, thus shutting down the worker processes which meet the new lower idle timeout. Let’s see in detail how the feature works:

By default the feature is disabled, so the default value for dynamicIdleThreshold is 0. The value set for this attribute is interpreted as ‘% of physical memory(RAM) committed’. So, what is committed memory, it is the processes virtual memory allocations for which the OS has allocated(or committed) a page in the physical memory and/or in the page file. The dynamicIdleThreshold feature will kick in when the total committed memory reaches 80% of the value that is set for the dynamicIdleThreshold. Let’s take an example to understand this better:

Let’s say we have a machine with 2GB physical memory and we set the dynamicIdleThreshold to 150. So the feature will kick in when the total committed memory reaches 80% of 3GB(150% of 2GB) which is 2.4GB. Note that the limit for the committed memory is greater than your physical memory, this limit is typically the sum of the physical memory(excluding the system memory part) and total paging files size on the machine. The following table lists, by how much the idle timeout will be cut, remember that it is windows process activation service(WAS) which is doing the idle timeout chopping:

On the other side should the committed memory usage fall below 75% of the configured dynamicIdleThreshold value WAS will restore the original idle timeout settings.

In our internal testing we have seen that setting the dynamicIdleThreshold to around 130 gives optimum performance in a webhosting environment. Use trial and error to find out what will be a good value for your webhosting environment.

So as you can see from the above description the feature limits the number of worker processes that can be run at any point of time by shutting down the least used processes and thus allowing new requests to be served. Compare this to Windows 2003 where in, once you have run out of memory, new request would see ‘service unavailable’ errors, you have to wait till a worker process times out and shuts down freeing up memory for a new worker processes to be launched. Thus on Windows 2008 if you enable this feature you are pretty much guaranteeing that a new request will be served even if the memory is scarce.

3. The new configuration system in IIS7 now supports thousands of sites and application pools that could be used in the web hosting scenario. IIS7’s configuration system is scalable to thousands of sites. You might want to use the new API’s like Microsoft.Web.Administration namespace, Microsoft.ApplicationHost.WritableAdminManager or the appcmd tool to provision hundreds of sites at a time instead of the older API’s like ADSI or WMI which are quite slow when it comes to provisioning new sites and applications.