Using the ASP.NET Process Model
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1
One of the most important requirements for .NET Framework applications is reliability. An architecture in which applications run inside the server process (in IIS, Inetinfo.exe) does not produce a solid foundation for building reliable applications that can continue to run over a long period of time. Too many resources are shared on the process level, and it is too easy for an error to bring down the entire server process.
To solve this problem, ASP.NET provides an out-of-process execution model, Aspnet_wp.exe, which helps protect the server process from user code. It also enables you to apply heuristics to the lifetime of the process to improve the availability of your Web applications. Using asynchronous interprocess communication helps provide a balance between performance, scalability, and reliability.
Process model settings are exposed in the root configuration file for the computer, Machine.config. The configuration section is named <processModel> Element and is shown in the following example. On computers running Windows 2000 and Windows XP, the process model is enabled by default (enable="true").
Note
On computers running Windows Server 2003, ASP.NET runs in IIS 6.0 worker process isolation mode by default. If your application is designed with specific ASP.NET process model settings, to be able to use them on Windows Server 2003 you must configure the server to run in IIS 5.0 isolation mode. For more information, see Configuring Isolation Modes.
<processModel
enable="true"
timeout="Infinite"
idleTimeout="Infinite"
shutdownTimeout="0:00:05"
requestLimit="Infinite"
requestQueueLimit="5000"
restartQueueLimit="10"
memoryLimit="60"
webGarden="false"
cpuMask="0xffffffff"
userName="machine"
password="AutoGenerate"
logLevel="Errors"
clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
responseRestartDeadlockInterval="00:09:00"
responseDeadlockInterval="00:03:00"
maxWorkerThreads="20"
maxIoThreads="20"
/>
Most of configuration settings in this example help control when a new worker process begins to serve requests (gracefully taking the place of an old worker process). The userName and password attributes define the account under which the ASP.NET worker process runs. These default to the values machine and autogenerate, respectively. These values tell ASP.NET to use the built-in ASPNET account and to use a cryptographically strong random password stored in the Local Security Authority (LSA) for that account.
Note
On computers running Windows Server 2003, by default ASP.NET runs as part of the IIS 6.0 (W3wp.exe) process using the default identity NETWORK SERVICE. If IIS5 isolation mode is configured on a computer running Windows Server 2003, the ASP.NET worker process runs in the ASPNET account.
If you want a more privileged process, you can set the userName attribute to System, which causes the ASP.NET worker process to run with the same identity as the Inetinfo.exe process. This process runs by default as the System identity. When so configured, the ASP.NET worker process will have the right to access nearly all resources on the local server. In Windows 2000, Windows XP, and Windows Server 2003 family systems, the System account also has network credentials and can access network resources as the machine account.
Warning
Caution
Changing the userName attribute to System enables access to and the ability to alter nearly all the resources on the computer, creating a significant security risk to your server.
The following example changes the userName attribute in the <processModel> section of the Machine.config file to run the process as System.
<processModel userName="system" password="autogenerate" />
The process model supports two types of recycling: reactive and proactive.
Reactive Process Recycling
Reactive process recycling occurs when a process is not functioning properly or is unable to serve requests. The process typically displays detectable symptoms, such as deadlocks, access violations, memory leaks, and so on, in order to trigger a process recycle. You can help control the conditions that cause a process restart by using the requestQueueLimit, memoryLimit, and shutdownTimeout configuration attributes. For more information about these attributes, see the <processModel> Element configuration section.
Proactive Process Recycling
Proactive process recycling restarts the worker process periodically even if the process is healthy. This can be a useful way to prevent denials of service due to conditions the process model is unable to detect. A process can be restarted after a specific number of requests or after a time-out period has elapsed. You can enable proactive process recycling using the timeout, idleTimeout, and requestLimit configuration attributes. For more information, see the <processModel> Element configuration section.
Logging Process Model Events
The process model can write events to the Windows event log when process cycling occurs. This is controlled by the logLevel configuration attribute. For more information, see the <processModel> Element configuration section.
When a cycling event occurs, if logging is enabled for that event, the following entries are written to the application event log.
| Shutdown reason | Event Log Type | Description |
|---|---|---|
Unexpected |
Error |
The ASP.NET worker process shut down unexpectedly. |
RequestQueueLimit |
Error |
The ASP.NET worker process restarted because the request queue limit was exceeded. |
RequestLimit |
Information |
The ASP.NET worker process restarted because the request limit was exceeded. |
Timeout |
Information |
The ASP.NET worker process restarted because the time-out interval was met. |
IdleTimeout |
Information |
The ASP.NET worker process shut down because the idle time-out interval was met. |
MemoryLimitExceeded |
Error |
The ASP.NET worker process restarted because the process memory limit was exceeded. |
Enabling Web Gardens on Multiprocessor Computers
The process model helps enable scalability on multiprocessor computers by distributing the work to several processes, one per CPU, each with the processor affinity set to its own CPU. This eliminates cross-processor lock contention and is ideal for large symmetric multiprocessing (SMP) systems. This technique is called Web gardening. To enable Web gardening, you need to set the cpuMask and webGarden configuration settings in the <processModel> element. The following example enables Web gardening on a server running ASP.NET.
<configuration>
<system.web>
<processModel
enable="true"
timeout="15"
webGarden="true"
maxWorkerThreads="25"
maxIoThreads="25"/>
</system.web>
</configuration>
Web gardening has some side effects that you should be aware of:
If your application uses session state, it must choose an out-of-process provider (NT Service or SQL).
Application state and application statistics are per process, not per computer.
Caching is per process, not per computer.