How To Increase IIS Performance Using Web Garden
Shortly after implementing this change, we set our record for most active concurrent user's - which is 991. With this load we still had memory and CPU available. Page response was instantaneous. Throughput in mySQL has since reached a max of 140 queries/second! The prior high was about 20. We feel we could currently handle 1500 or more concurrent sessions, with the ability to scale more if we just add some RAM.
If you've been involved with any sort of serious web hosting environments the term "Web Farm" will be familiar to you. This is where multiple computing environments are brought together to act as one to bolster computing power. IIS 6 brought a new feature to the table called a "Web Garden" which is a similar concept of colating computer power except this time using software on a single hardware node. A Web Garden can only be used when IIS is running in worker process isolation mode (default), and is configured on a per application pool level. The idea behind configuring an application pool to use multiple worker processes (i.e a Web Garden) is to improve scalibility and reliability, however in practice this has not always been the case with single CPU/Core systems as these worker processes are all competing for the same CPU time. However since multi processor and multi core CPU systems have become the rule rather than the exception for low/medium spec servers over the last few years the advantage of using a a Web Garden have started to make a lot more sense. Just recently while posting on the IIS.net forums I came across a situation where a systems adminstrator was at wits end because he had a server with 8 CPU's running a busy PHP/MySQL based forum which was giving terrible performance to users despite the fact that the CPU utilisation of the system was only sitting at about 15%. As it turns out this environment was a prime candidate for using a Web Garden which is exactly what he did.
Under a default installation of IIS 6 only a single worker process (w3wp.exe in your process list) is spawned to service each application pool. This is how the server in question was originally configured, and this was the observation made of the system;
Under a default installation of IIS 6 only a single worker process (w3wp.exe in your process list) is spawned to service each application pool. This is how the server in question was originally configured, and this was the observation made of the system;
Under normal load we have about 300 users browsing our boards. Under 'peak' load, we can only handle about 500 users. Our user base would probably allow us to get 2000 or more concurrent users at a time, but our server is holding us back. Under peak load, The IIS process is using about 15% of CPU, and about 450,000 MB of RAM. There is always 1GB or more of free memory available. Disk I/O is fine per Performance Manager. My MySql database is also fine. During peak load, the site becomes unresponsive. Clicks take two minutes or more.
Obviously not ideal, and likewise not your run of the mill performance issue as there were still a massive amount of system resources left. After some general troubleshooting to ensure basic PHP and MySQL configuration directives and performance values where as they should be it became obvious that the bottleneck was the web environment. The next move was to create a web gardenwhich had immediate results;
I upped our worker threads for our message boards from 1 to 8 (we have 8 procs). Bingo! Finally the memory and CPU's start to actually get used. My queries per second in mySQL went from a prior max of 20/sec to 60+/sec. Up your worker processes from the default to get more out of your PHP/IIS solutions!
So creating the web garden did the trick, and the server has now able to utilize a lot more of the hardware resources. How far could it go though?
Shortly after implementing this change, we set our record for most active concurrent user's - which is 991. With this load we still had memory and CPU available. Page response was instantaneous. Throughput in mySQL has since reached a max of 140 queries/second! The prior high was about 20. We feel we could currently handle 1500 or more concurrent sessions, with the ability to scale more if we just add some RAM.
So in this case going from an IIS 6 application pool using just the one worker process to a web garden using 8 worker processes (one worker process per physical CPU/core) tripled the concurrent session capacity and slashed response times. Obviously not everyone is going to have a server with 8 CPU's, but with dual and quad core systems now commonplace there is still significant performance potential in configuring your IIS 6 server application pools to use a web garden to maximize the use of computing power.