Developer

SolutionBase: Stabilize Web servers by using application pools

These application pool techniques help prevent Web sites from crashing Web servers.


As you may know, IIS has long been capable of hosting multiple Web sites. However, doing so can be dangerous. A problem on one Web site can affect every site on the server. For example, suppose one of the Web sites on a server hosting multiple Web sites had a Web application with a memory leak. In IIS 5, this could potentially cause the buggy Web site to completely drain the server of memory, given enough time. In a more extreme case, a buggy Web site could potentially crash all of the other Web sites on the server and, in some cases, even bring down the server itself. The good news is that Microsoft realized just how serious a problem this was and corrected it in Windows Server 2003 and IIS 6 through the implementation of application pools.

Application pools
Each application pool uses its own set of server resources. Therefore, if a Web site were to cause a massive crash, only the application pool containing the site would be affected. There's very little chance of the crash bringing down the entire server or causing problems with sites in other application pools.

If you want to isolate each Web site on a server, all you have to do is place each Web site into its own application pool. Unfortunately, IIS 6 doesn't implement multiple application pools by default; you have to put each Web site into its own application pool yourself. There's only one application pool, and all hosted sites are lumped into it. This prevents a buggy Web site from crashing a server, but it does nothing to prevent Web sites from interfering with each other. For that, you'll have to create some application pools and move the various Web sites into them.

Creating application pools
Begin by opening the Internet Information Services (IIS) Manager. When the console opens, navigate through the console tree to Internet Information Service\your server\Application Pools. When you expand the Application Pools container, there should be one application pool already in existence—DefaultAppPool (as the name implies, it's the default application pool). Depending on your server's configuration, there may be a few other application pools that already exist. The latest versions of Exchange Server and SharePoint Portal Server both create their own application pools.

If you want to create a new application pool, all you have to do is right-click the Application Pools container and select New | Application Pool from the resulting shortcut menu. You'll see a screen that asks you to enter a name for the new application pool. You also have a choice of using the default application pool settings or using another application pool as a template. Since this is your server's first application pool (other than the default application pool), just enter a name, choose the option to use the default settings, and click OK.

That's all there is to creating an application pool. There are some settings that you can tweak to control the application pool's behavior, which I'll show you a bit later. For now, though, you've created a fully functional application pool. Remember, however, that an application pool by itself doesn't do anything.

To get any benefit from the application pool you just created, you must move a Web site into it. To do so, right-click on the Web site and then select the Properties command from the resulting shortcut menu to open the Web site's properties sheet. Navigate to the properties sheet's Home Directory tab, and you'll see a drop-down list at the bottom of the window that allows you to select the application pool in which you want the site to reside (Figure A).

Figure A
The Home Directory tab allows you to select which application pool the site should belong to.


Fine-tuning an application pool
So far, I've shown you how to create an application pool and insert a Web site into it. Although this is enough to get by on, there are a number of settings within the application pool that you can fine-tune in order to tweak the application pool's behavior.

Even if you choose not to tweak the application pool's behavior, Web sites within the application pool will be isolated from those in other application pools. The benefit of fine-tuning an application pool is that you can make a buggy Web site more stable. For example, if a Web site is known to have a memory leak, you can reset the site on a periodic basis to reclaim lost memory.

To fine-tune an application pool, right-click it and select the Properties command from the resulting shortcut menu. The application pool's properties sheet will appear, and the Recycling tab will be selected by default, as shown in Figure B.

Figure B
The Recycling tab controls how often the application pool is reset.


As you look at the Recycling tab, forget everything that you know about the Windows Recycle Bin, because the Recycling tab has absolutely nothing to do with it. In this particular case, the term recycling means resetting or rebooting. On the Recycling tab, notice the many references to the worker process.

Earlier, I said that each application pool uses its own set of system resources. To be more technically correct, each application pool uses a dedicated process for hosting the Web sites that it contains. This process is known in IIS terms as the worker process.

In Figure A, notice that, by default, the Application pool is set to recycle (reboot or reset) the worker process every 1,740 minutes (every 29 hours). Since some Web applications tend to have bugs that cause memory leaks, resetting the process allows IIS to recoup memory lost to a leaky Web application.

There are also options for resetting the worker process at specific times or after a certain number of requests. You'd reset the worker process at specific times if you wanted to start the process with a clean slate each day. For example, you could recycle the process every morning at 6:00.

Recycling the process after a certain number of requests usually pertains to applications with known memory leaks. For example, if you tracked the system's memory and were able to determine that memory got to be a problem after about 50,000 requests, you could recycle the worker process before memory usage could become an issue.

At the bottom of the Properties box, you have the option of recycling the worker process based on how much memory it is using rather than on the number of requests, time of day, or number of hours since the last recycling operation. You can specify memory thresholds in terms of physical memory and/or virtual memory consumed by the application pool. Once the threshold is crossed, the worker process will be recycled.

The Performance tab
We've all seen an application that hogs a server's resources. The same problem can occur on a Web server. Left unchecked, a Web site that gets a lot of traffic can consume so much CPU time that less active Web sites do not get enough CPU time to function properly. Fortunately, regulating CPU time is one of the things you can do with application pools. All CPU time regulations are controlled through the Performance tab of the application pool's properties sheet, shown in Figure C.

Figure C
The Performance tab lets you control how much of a workload an application pool can place on a processor.


Before I examine the settings on this tab, there's one concept you need to understand. No law says that an application pool is limited to using a single worker process. When required, an application pool can use multiple worker processes. That's why the top portion of the Performance tab refers to the Idle Timeout period.

If a worker process is idle for longer than the specified amount of time, the process is terminated. Remember that simply terminating the process doesn't take the Web site offline. It merely removes worker processes that are no longer in use.

The next section of the Performance tab is the Request Queue Limit section, which allows you to limit the number of inbound requests that can be queued at a time. This prevents Web sites within the application pool from becoming too backlogged. If more than the specified number of requests piles up in the queue, additional requests are turned away, and the server sends an error message to those making the request.

Next is the CPU Monitoring section. When CPU monitoring is enabled, you must set the maximum CPU usage in terms of the system's total capacity. By default, the application pool is allowed to use 100 percent of the CPU's capacity. After selecting the percentage of CPU time that the application pool is allowed to use, you must also set the action to be performed when the allocated CPU time is exceeded.

By default, no action is taken. This is a bit misleading, though. Technically, an action is taken because an error message is written to the event logs. The other option is Shutdown, which terminates the worker processes within the application pool when they begin using too much CPU time.

Suppose you allow an application pool to use 80 percent of the CPU time. If the CPU were to go through a busy period in which activity spiked to 100 percent every few seconds, your event logs could become flooded with error messages. To keep that from happening, you can set the Refresh CPU Usage Numbers. This is a time period (in minutes) that you want to check to see how busy the CPU is. The default value is five minutes. This means that no matter how busy the CPU might be, you won't get an error in the event logs at a rate of more than once every five minutes.

The final option on the Performance tab is Web Garden. This is just a fancy way of determining the maximum number of worker processes that the application pool is allowed to create.

The Health tab
The Health tab, shown in Figure D, allows IIS to make determinations as to whether the application pool is functioning correctly or not. The first option on this tab is Enable Pinging. When this option is selected, IIS will ping the application pool periodically to see if the application pool responds. If it does, it is assumed to be healthy. By default, the ping occurs every 30 seconds, but you can adjust this time period to fit your needs.

Figure D
The Health tab allows IIS to determine whether an application pool is functional and to take appropriate action during failures.


In the Enable Rapid Fail Protection section, you can specify an acceptable number of failed pings that can occur within a certain length of time. By default, this section is set with a threshold value of five failures in five minutes. If more than five failures occur within five minutes, the application pool will return an "out of service" message to all requests until the application pool can be recycled.

At the bottom of the Health tab is a startup and shutdown time limit. This is the maximum amount of time that a worker process should take to start up or shut down. If a process takes longer, it is assumed that there is a problem, and the process is automatically terminated.

The Identity tab
The Identity tab, shown in Figure E, lets you select an application pool identity. Basically, this means that you must designate a security account for the application pool. A predefined account is used by default, but you have the option of manually specifying an account if you want.

Figure E
The Identity tab lets you associate a security account with the application pool.

Editor's Picks

Free Newsletters, In your Inbox