Process Management

One of the main features that we want in a Web server is unattended 24/7 operation. This level of service is a problem developers never really had to address in writing desktop applications. For example, memory leaks in a Solitaire game that runs for 5 minutes at a time (OK, 2 hours) probably won’t waste enough memory to hurt anything. But if I kept the Solitaire game running for a year, redealing instead of closing it, any memory leaks would eventually exhaust the process’s address space and cause a crash.

Robustness under load is a very important feature of a Web server.

That sort of robustness is very hard to develop, partly because it takes a long time to test. The only way to find out whether something runs for two weeks under load is to run it under load for two weeks. And when the crash does happen, it’s often caused by a banana peel dropped days earlier, which is essentially impossible to find at the time of the crash.

It’s also extremely difficult to develop. That figures.

I once (14 years ago) worked on an application that ran in a major bank. It was a DOS-based system (remember DOS?) that would usually run all day, but it just couldn’t run for a week without crashing and we couldn’t wring it out so that it could. I had the bright idea of putting a watchdog timer card into the machine that our software would periodically reset while it ran. If the timer ever actually expired without being reset, it would automatically reboot the system, sort of a “dead-geek” switch. The bank balked at installing such a god-awful kludge (we probably shouldn’t have told them; we probably should have just done it and smiled) and instead agreed to have the administrator reboot the system every night.

Most software needs periodic restarting.

Original ASP kept a user process running indefinitely. Any bugs or memory leaks in any of the user code would accumulate and eventually cause crashes. ASP.NET recognizes that user code probably isn’t going to be perfect. It therefore allows an administrator to configure the server to periodically shut down and restart worker processes.

ASP.NET supports process recycling to continue working robustly in the face of imperfect user code.

You configure process recycling using the <processModel> element of the machine-level machine.config file, as shown in Listing 3-17. I wish Microsoft had allowed process model configuration on a per-application basis, but they haven’t at the time of this writing. You can tell ASP.NET to shut down your worker process and launch a new one after a specified amount of time (timeout attribute), a specified number of page requests (requestLimit attribute), or if the percentage of system memory it consumes grows too large (memoryLimit attribute). While not removing the need to make your code as robust as possible, this will allow you to run with a few memory leaks without rebooting the server every day or two. You can see that the process model contains other configurable capabilities as well. IIS 6.0, which is scheduled to ship with Windows Server 2003, contains a mode called worker process isolation. When this mode is active, ASP.NET’s process model settings are ignored in favor of IIS’s own internal settings that provide the same sorts of functionality.

You configure process recycling in the machine.config file.

Listing 3-17: Machine.config file showing process recycling settings.

<processModel enable="true" timeout="infinite" idleTimeout="infinite" shutdownTimeout="0:00:05"  requestLimit="infinite"  requestQueueLimit="5000"  memoryLimit="80"  webGarden="false" cpuMask="0xffffffff" userName="" password="" logLevel="errors" clientConnectedCheck="0:00:05" />