Introduction
This article describes the concept of application pools and web garden that has been introduced in IIS 6.0 and tuning IIS 6.0 for better performance. I have tried to keep it simple and short, at the same time informative.
Fundamentals
What is an Application Pool?
IIS can isolate an individual Web application or multiple sites into a self-contained process (called an application pool) that communicates directly with the Operating System kernel.
What is a Web Garden?
IIS 6.0 worker process isolation modes also enable multiple worker processes to be configured to service requests for a given application pool. This configuration is known as a Web garden.
IIS 6.0 Architecture
The figure below describes the IIS 6.0 architecture in its simplest form. Unlike previous versions of IIS, there are multiple processes (application pools) that run independent of each other. The biggest advantage of this (isolation of processes) is, in a shared hosting environment, when one of the web sites goes down because of a heavy load, that doesn't effect the other websites that are running under a different application pool.
Moreover, the IIS 6.0 manager allows you to limit the max memory that can be used by an application pool. It also allows you to configure parameters related to the performance and health of an application pool.
Advantages of using this feature
- These self-contained application pools prevent an application or site from disrupting the XML Web Services or other Web applications on the server.
- OS resource (memory, CPU utilization etc.) allocation.
- Isolation increases throughput, and increases the capacity of applications.
- Offers more headroom on servers, which in turn reduces hardware needs.
- Through web garden and processor affinity, increases throughput and capacity of applications.
Other settings that affect the reliability and availability of a web application on IIS 6.0:
- Health monitoring
- Automatic process recycling
- Rapid fail protection
Case study (out of my experience)
I worked with a Web Service (5 instances for 5 different clients), which when hosted on IIS 5.1 used to handle 90K requests per day and with a peak of 3 requests in a fraction of a millisecond. But as the traffic started increasing slowly and the application slowed down in peak time, it was not able to handle 3 requests in a fraction of a second.
The same Web Service was deployed on IIS 6.0. An application pool was created for each client instance, with different resource settings (based on the load expected from that particular client). To our surprise, the server with the same hardware and the same application was able to handle 300K requests per day with a peak of 12 requests in a fraction of a millisecond without any problem.
Precautions
- Too many worker processes could slow down the web application.
- Improper allocation of the resources could slow down the web application performance.
- Improper tuning of the health monitoring and recycling parameter could slow down the web application performance.
Points of interest
With the same hardware, you can get an unbelievable improvement in web application/service performance, provided you make use of IIS 6.0 and configure the application pools in a proper manner.
References
