If your IIS Server hosts multiple Web sites, then buggy code within any one of those sites can bring down the other sites. I should know; it happened to me. Fortunately, there is something that you can do to prevent this from happening. In this article, I will show you how you can use application pools to prevent problems with a Web site from causing stability problems across your IIS server.
On April 22, 2003, I was hosting a live discussion on my Web site related to E-mail archiving. Half way through the chat, my screen went blank and I received a bandwidth limit exceeded error message. Since I had developed the chat software myself, I knew that the error message wasn’t part of the software. It had to be related to a limitation that my Web host had imposed. To make matters worse, everyone who was participating in the chat was kicked out of the site and most were not able to reconnect because the site thought that they were still logged in. Since I was the one hosting the event on my Web site, that I had developed myself, the problem was a little embarrassing to say the least.
Once I managed to re-establish my connection and conclude the chat, I made a frantic phone call to my Web host to find out what had happened. The Web host was very surprised by the event and told me that they don’t do anything to limit my bandwidth. To make a long story short, I sent my Web host a screen shot of the error message, and they investigated the problem. It turns out that someone else who was hosting a Web site with them had installed a shareware bandwidth monitoring program as a part of their Web site. Even though this application was not a part of my Web site, it was able to crash my site because of the way that Internet Information Server shares resources among hosted Web sites.
I posted a transcript from the chat on my Web site. If you go to http://www.brienposey.com/kb/navistore-chat-2.asp and scroll to about two thirds of the way down the page, you can see where the crash happened and where everyone was trying to reconnect. I am giving you this link to prove a point. The point is that I did not make this story up. If an IIS server is hosting multiple Web sites, then a problem on one site can cause problems on other sites. It happened to me and it can happen to you; unless you use application pools to isolate your site.
What is an Application Pool
An application pool provides you with a way of isolating Web sites from each other even though they are being hosted on a common server. Each application pool is given its own set of server resources. That way, if a Web site crashes, it won’t effect sites in other application pools. A classic example of this is a Web site with a memory leak. If all of the Web sites hosted on a particular server were to share system resources, and one of the Web sites had a memory leak, it could potentially take memory away from the other hosted sites. If the leaky site were in its own application pool though, the memory leak would not effect any other site because each application pool has its own server resources (including memory).
Before I Begin
Before I start showing you how to set up application pools, there are a few things that you need to know about them. First, application pools are available only when the HTTP service is running in worker process isolation mode (this is the default). If you are running IIS in IIS 5 isolation mode, then the application pools will not be accessible to you.
Another important tidbit of information is that even though IIS 6 allows you to use application pools, there is only one application pool by default. As you create new Web sites on the server, the newly created sites are lumped into the default application pool unless you tell IIS to do otherwise. IIS will not automatically create a separate application pool for each Web site.
The other thing that I want to point out before I get started is that in the sections that follow, there will be a lot of references to worker processes. A worker process is simply a process that actually runs the Web site. Each application pool has one or more worker processes. The worker processes are unique to the application pool and are not shared across application pools.
Creating a New Application Pool
Now that I have explained what application pools are, let’s look at how to create one. If you want to create an application pool, all you have to do is to open the Internet Information Services (IIS) Manager, right click on the Application Pools container, and select the New | Application Pool commands from the shortcut menus. When you do, you will see a dialog box that asks you to give IIS a name for the new application pool. I usually give the application pool a name that reflects which Web site it will be used with. Make sure that the Use Default Settings option is selected, click OK, and the application pool will be created.
Just because you create an application pool, it doesn’t mean that any of your Web sites are going to use it. To make a Web site use a specific application pool, you must right click on the Web site and select the Properties command from the shortcut menu to reveal the Web site’s properties sheet. When the properties sheet appears, select the Home Directory tab. There is an option at the bottom of this tab that allows you to select which application pool the site will use.
Configuring an Application Pool
Normally, you don’t have to do anything else to the application pool. However, there are quite a few ways that you can fine tune the application pool’s behavior if you’d like. To do so, right click on the application pool and select the Properties command from the resulting shortcut menu. When you do, you will see the application pool’s properties sheet, as shown in Figure A.
Figure A: You can fine tune the behavior of an application pool
As you can see in the figure, the default tab is the Recycling tab. Recycling simply refers to restarting the worker process. Just as a computer sometimes performs better after it has been rebooted, worker processes also need to be “rebooted” once in a while to keep them running well.
By default, IIS recycles the worker process every 1740 minutes (29 hours). However, there is also an option to recycle the worker process after a specific number of requests (this is good for busy Web sites) or at certain times of the day.
The bottom of this tab contains a couple of options for recycling the worker process based on memory usage. You can recycle the worker process once it uses a certain amount of virtual memory or once it is using a certain amount of physical memory. This feature is excellent for preventing memory leaks from causing performance problems.
The Performance Tab
The Performance tab, shown in Figure B, is designed to keep the application pool running efficiently. The first option on the page shuts down the worker process after the site has been idle for 20 minutes. This helps to give the server processing power and memory resources that it can use for other things until the worker process is needed again.
Figure B: The Performance tab is designed to keep the application pool running efficiently
The next option allows you to limit the inbound request queue length. By doing so, you can make sure that the site doesn’t get slammed with more requests than it can handle.
The next portion of the Performance tab has to do with CPU monitoring. CPU monitoring allows you to prevent a demanding Web application from hogging the server’s CPU resources. You can set the maximum percentage of CPU time that the worker process is allowed to use. If this value is exceeded, you can recycle the worker process.
The last option on this tab is the maximum number of worker processes. As I said earlier, each application pool has at least one worker process. If an application pool contains more than one Web site, it can sometimes realize greater performance if you allow multiple worker processes.
The Health tab, shown in Figure C, provides you with the ability to make sure that the worker processes that the application pool is using are healthy. The first option on this tab is the enable pinging check box. If you select this option, then IIS will ping the pool’s worker processes every 30 seconds to make sure that they are responsive.
Figure C: The Health tab allows IIS to monitor worker processes to make sure that they are healthy and responsive
The next check box on the Health tab is the Enable Rapid Fail Protection check box. The idea here is that IIS can completely disable an application pool if there are a certain number of failures within a specific length of time. For example, by default if the worker process fails five times in five minutes, then the application pool will be disabled. The reason for doing this is that if a worker process is failing that often then there must be a serious glitch either with the system or with one of the Web sites within the application pool. IIS takes the application pool down in the interest of preserving the server’s overall stability.
The last two options on this tab aren’t really a big deal. They simply dictate the length of time that is acceptable for a worker process to startup and shut down. In the real world, I have never seen a worker process time out on startup or shutdown, so chances are that you may never have to touch these values.
The identity tab, shown in Figure D, allows you to choose which service account’s credentials the application pool will use. Normally, you will just want to go with the default settings here and use the Network Service.
Figure D: The identity tab allows you to choose which service account’s credentials the application pool will use
In this article, I have explained that a problem with one Web site can effect other Web sites hosted by the server. However, you can prevent these problems by placing each hosted Web site into its own application pool