ASP.net's process model
Working with the process model
Process model Configuration
Passive Process Recycling
Active Process Recycling
Logging Process Model Events
Enable Network Garden
Summary of this section
--------------------------------------------------------------------------------
One of the most important requirements for ASP.net framework applications is reliability. The structure of applications running within a server process (Inetinfo.exe in IIS) does not provide a solid foundation for generating reliable applications that can continue to run for long periods of time. Too many resources are shared at the process level, and it is too easy for an error to crash the entire server process.
To resolve this issue, ASP.net provides an out-of-process execution model that protects the server process from user code interference. It also enables you to apply intuitive inference to the lifetime of a process to improve the usability of your WEB application. By using asynchronous interprocess communication, you can achieve the best balance between performance, scalability, and reliability.
Process model Configuration
The process model settings are exposed in the root configuration file machine.config of the computer. The configuration section is named <processmodel>, as shown in the following example. The process model (enable= "true") is enabled by default.
<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"
/>
Most of these settings control when a new worker process is started for the request service (normally replacing the old worker process). The process model supports two types of recycling: active and passive.
Passive Process Recycling
A passive process recycle occurs when the process behaves erratically or cannot be serviced for the request. Processes typically display detectable indications, such as deadlocks, access violations, memory leaks, and so on, to trigger process recycling. You can use the configuration settings described in the following table to control the conditions under which a restart process is triggered.
Setup Description
requestQueueLimit handles deadlock conditions. This DWORD value is set to the maximum number of requests allowed in the queue, exceeding which the worker process behaves erratically. When this value is exceeded, a new process is started and the request is reassigned. The default value is 5,000 requests.
MEMORYLIMIT handles memory leak conditions. This DWORD value is set to the percentage of physical memory that the worker process can use, exceeding which the worker process behaves erratically. When this percentage is exceeded, a new process is started and the request is reassigned. The default value is 80%.
