Web applications have long presented a special kind of problem for systems administrators. Often times, an application that works fine in a lab environment tends to be problematic in a production environment.
The reason why this is a problem for admins has to do with simple politics. The application developers often won't admit fault, because the application worked fine when they tested it. From their point of view, the administrator must have misconfigured the server that hosts the application.
From the systems administrator's standpoint, though, they are being asked to host an application that they know nothing about. The Web server itself is working fine prior to publishing the application, so any problems that occur later on must be related to the application.
In the years that I have been working with Internet Information Services (IIS), I have seen these types of situations develop into heated battles time and time again. Often, however, a little research reveals that the application works fine under a moderate workload. But when the server starts receiving an excessive number of requests, the application consumes more and more server resources until problems result.
In these types of situations, occasionally resetting an application can release the resources that the application has consumed, thus preventing the resource consumption from becoming problematic. Fortunately, you don't have to reset Web applications manually. You can configure IIS to recycle (reset) worker processes automatically.
When to use worker process recycling
I first want to point out that you shouldn't depend on this to act as a substitute for writing good code, nor should it be a substitute for fixing a buggy application. There are, however, a number of situations when you can -- and should -- implement worker process recycling.
Worker process recycling is a particularly effective technique in the following situations:
When a Web application contains a bug that cannot be fixed
When an application contains a memory leak
When service level agreements or corporate policies prevent you from fixing the buggy code
When you have yet to determine the source of the problem
The other thing you need to know is that worker processes are linked to application pools. This is important because if an application pool contains multiple Web applications, then recycling worker processes will effect each application in the pool.
Configuring worker process recycling
With that in mind, you can configure worker process recycling by opening the Internet Information Service Manager and navigating through the console tree to your server, application pool, then to the application pool that you need to modify. Next, right click on the application pool, and select the Properties command from the resulting shortcut menu. When you do, Windows will display the application pool's properties sheet, as shown in Figure A.
Figure A
As you can see in the figure, the majority of the options related to recycling worker processes can be found on the properties sheet's Recycling tab. This tab allows you to recycle worker processes at specific times or in specific time intervals. You also have the option of recycling worker processes after a specific number of requests or when the application pool has consumed a specific amount of memory (physical or virtual).
Although this tab is the primary repository for settings related to worker process isolation, there are some important settings found on the other tabs. For example, if you look at Figure B, you can see that there is a setting that allows you to automatically shut down a worker process once it has been idle for a specific period of time. This allows you to terminate processes that have locked up or that are not being used because requests are not being made against the server.
Note: By default, idle worker processes are shut down after 20 minutes of inactivity.
Figure B
The Health tab, shown in Figure C, allows you to define what it means for a worker process to be healthy. The first setting on this tab tells IIS to ping worker processes every 30 seconds (the time period is adjustable). If the worker process responds to the ping, then it is assumed to be functional.
The next group of settings on this tab are related to rapid fail protection. Essentially, this means that you can tell IIS that if multiple processes fail within a certain length of time, then you should assume that something has gone horribly wrong and shut down the application pool. By default, five failures in five minutes will trigger an application pool shutdown.
The final two settings found on the Health tab allow you to specify the maximum amount of time that a worker process can take to start up or to shut down.
Figure C
Remember, worker process recycling isn't a magical cure all for buggy applications, but in some instances, it can mean the difference between a production Web application doing its job -- or experiencing severe performance and stability problems.
|
| Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
|
|
