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").

<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.

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.

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.

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.

Related Information

• Overview of ASP.NET Process Isolation

• Process Model Modes

• processModel Element