asp.net| process |asp.net| process asp.net process mode
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%.
SHUTDOWNTIMEOUT specifies the time that the worker process itself shuts down (when: minutes: A string value in the second format). If the timeout expires, the ASP.net ISAPI closes the worker process. The default value is "00:00:05".
Active Process Recycling
The active process recycle periodically restarts the worker process, even if the process is normal. This may be a useful way to prevent a service from being rejected because of a condition that the process model cannot detect. A process can be restarted after a specific number of requests or when the timeout period has expired.
Setup Description
Timeout: A string value in seconds format, used to configure a time limit, after which a new worker process is started to replace the current process. The default value is infinite, which indicates that the process should not be restarted.
IdleTimeout When: minutes: Seconds format string, used to configure the amount of inactivity, after which the worker process will automatically shut down. The default value is infinite, which indicates that the process should not be restarted.
Requestlimit is set to a DWORD value of the number of requests, after which a new worker process is started to replace the current process. The default value is infinite, which indicates that the process should not be restarted.
Logging Process Model Events
The process model can write events to the Windows event log when a process loop occurs. This is controlled by the LogLevel property in the <processModel> configuration section.
Setup Description
The LogLevel control records process loop events to the event log. The value can be:
All: Logs all process loop events.
None: Events are not logged.
Errors: Only unexpected events are logged.
When a circular event occurs, the following event is written to the application event log if logging is enabled for the event.
Shutdown Reason Event Log type description
Unexpected error asp.net worker process has unexpectedly shut down.
requestQueueLimit error because the request queue limit was exceeded, the ASP.net worker process has been restarted.
Requestlimit information The ASP.net worker process has been restarted because the request limit was exceeded.
Timeout information Because the timeout interval has expired, the ASP.net worker process has been restarted.
IdleTimeout information The ASP.net worker process has been closed because the idle timeout interval has expired.
memorylimitexceeded error The ASP.net worker process has been restarted because the memory limit for the process has been exceeded.
Enable Network Garden
The process model helps enable scalability on multiprocessor computers, distribute work to multiple processes (one per CPU), and each process sets the processor relationship to its CPU. This eliminates lock contention between processors and is an ideal choice for large SMP systems. This technique is called Web gardening. The configuration settings that enable the network garden are listed in the following table. Note that these settings take effect only after the server restarts. For this change to occur, IIS must loop.
Setup Description
Webgarden controls CPU relationships. True indicates that the process should be related to the appropriate CPU. The default value is False.
The number of cpumask control processes and the working mechanism of the network garden. Start a process for each CPU that sets the corresponding bit in the mask to 1. When Usecpuaffinity is set to 0 o'clock, the Cpumask setting controls only the number of worker processes (the number of digits set to 1). The maximum number of worker processes allowed is the number of CPUs. By default, all CPUs are enabled and a worker process with the same number of CPUs is started. The default value is 0xFFFFFFFF.
You should understand some of the side effects of Web gardening:
If the application uses session state, it must pick an out-of-process provider (NT service or SQL).
Application state and application static are based on each process, not on a per-machine basis.
Caching is based on each process, not on a per-machine basis.
Summary of this section
asp.net provides an out-of-process execution model that allows server processes to be protected from user code interference. It also enables you to apply intuitive inference to the lifetime of a process to improve the overall usability of your WEB application.
<processModel> settings are exposed in the root configuration file of the computer's Machine.config file. The process model is enabled by default.
The process model supports two types of recycling: active and passive. A passive process recycle occurs when the process behaves erratically or cannot be serviced for the request. The active process recycle periodically restarts the worker process, even though the process may be quite normal.
The process model can write events to the Windows event log when a process loop occurs. This is controlled by the Log-level property in the <processModel> configuration section.
The process model helps enable scalability on multiprocessor computers, distribute work to multiple processes (one per CPU), and each process sets the processor relationship to its CPU. This technique is called Web gardening.
