Mukhtar's Blog

Webhosting Performance Tunings For IIS7

2009-04-21T01:46:19Z

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:

dynamicIdleThreshold percentage reached	Action
80%	WAS sets idle-timeout of all worker processes to ½ of original value.
85%	WAS sets idle-timeout of all worker processes to 1/4th of original value.
90%	WAS sets idle-timeout of all worker processes to 1/8th of original value.
95%	WAS sets idle-timeout of all worker processes to 1/16th of original value.
100%	WAS sets idle-timeout of all worker processes to 1/32 of original value.

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.

Sample WCAT script files

2009-04-02T01:58:00Z

At times you would want to make sure that you have the correct WCAT script files to verify that your WCAT setup is working correctly.

A copy of simple client scenario file aka client.ubr requesting the default document is as follows:

scenario
{
    name    = "default_doc";

    warmup      = 30;
    duration    = 90;
    cooldown    = 30;

    default
    {
        setheader
        {
            name    = "Connection";
            value   = "keep-alive";
        }
        setheader
        {
            name    = "Accept";
            value   = "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, */*";
        }
        setheader
        {
            name    = "Accept-Language";
            value   = "en-us";
        }
        setheader
        {
            name    = "User-Agent";
            value   = "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0";
        }
        setheader
        {
            name    = "Accept-Encoding";
            value   = "gzip, deflate";
        }
        setheader
        {
            name    = "Host";
            value   = server();
        }
        version     = HTTP11;
        statuscode  = 200;
        close       = ka;
    }

    transaction
    {
        id      = "default_doc";
        weight  = 100;

        request
        {
            url = "/";
        }
    }
}

A very basic WCAT settings file aka settings.ubr file querying just one counter on the server would look like:

settings
{
    counters
    {
        interval = 10;
        counter = "Memory\\Available MBytes";
    }
}

Troubleshooting WCAT(Web Capacity Analysis Tool) Problems

2009-03-16T15:18:00Z

The best approach to figure out what is wrong with your WCAT setup and scripts is to run it manually which typically involves:

Running the WCAT controller
Running one or more instances of WCAT client(s), the exact number is specified in the WCAT controller command in step 1 above

The advantage with this approach is that you would see errors ,if any, in the command window(s) and not miss them because of the command window closing down which is the case when running the .wsf script provided with the download.

Let's get into some details:

Running the WCAT controller

wcctl.exe is the WCAT controller executable, and a typical command for the controller would look as:

wcctl.exe -t client.ubr -f settings.ubr -s mywebserver -v 10 -c 1 -o wcat_log.xml -x

Some of the switches in the above command can also be specified in the WCAT settings file - settings.ubr. If a switch is specified in the command line it will override the one in the settings file. Let's briefly look at the arguments in the above command:

-t    client scenario file containing the URL's that will be requested by the client(s), you can specify an explicit or a relative path for the file

-f    controller settings file, typically will specify the performance counters that need to be measured on the server, can also specify client scenario file to use, server to which request are to be send etc, you can specify an explicit or a relative path for the file

-s    web server to be stressed

-v    virtual clients per physical client to be used

-c    number of physical clients used to stress the web server

-o    output WCAT log file that gets generated at the end of the test

-x    generate extended information, if you skip this switch the performance counters will not show up in the output log file even if you have them specified in the controller settings file, you will also miss the 'Server Information' section in the report, if you are stressing a Linux server specifying this switch will have no effect, meaning it will not collect the extended information

Running the WCAT client

wcclient.exe is the WCAT client executable, its' job is to make requests that are specified in the client scenario file, typically you would run it as follows:

wcclient.exe wcat_controller_machine_name

As you can see wcclient.exe takes only one argument(unless you are stressing over IPV6 in which case you have to also specify the –i switch), this is the name of the WCAT controller machine.

Depending on the number of physical clients you have specified for the controller command, you may have to run the above command that many times. For example if we would have specified -c 2 for the wcctl command, we would have to run wcclient command two times, ideally from two physical client machines. If you are running multiple instances of the client from individual physical client machines I would run a simple batch script as follows on the client machines so that I don’t have to run the WCAT client from these individual machines every time I run the controller:

:LOOP
timeout -t 5
C:\wcat6.1\wcclient.exe wcat_controller_machine_name
goto LOOP

Make sure the path is valid on your client machines. Once your WCAT client connects to the controller, you should either see an error in both the client and controller command windows or the test should run.