Home   |   QuickStart Welcome   |   ASP.NET   |   Web Services   |   How Do I...?   
  |   I want my samples in...      

ASP.NET 2.0 Quickstart Tutorials

Configuring the Process Model

One of the most important requirements for ASP.NET Framework applications is reliability. The architecture of applications running 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, which protects 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 enables you to provide the best balance of performance, scalability, and reliability.

Process Model Configuration

Process model settings are exposed in the root configuration file for the computer, Machine.config. The configuration section is named <processModel> and is shown in the following example. On Windows 2000 and Windows XP, the process model is enabled by default (enable="true").

On the Windows Server 2003 family, ASP.NET runs in IIS6 native mode (Worker Process Isolation Mode), and the <processModel> section is ignored, and built-in IIS6 process model settings are used instead. ASP.NET 2.0 does not support running in the IIS5 Isolation (compatibility) mode of IIS6.

<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 these settings control when a new worker process is started to serve requests (gracefully taking the place of an old worker process). The process model supports two types of recycling: reactive and proactive. The 'userName' and 'password' attributes define the account under which the ASP.NET worker process runs.  These default to '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.  As noted above, by default on the Windows Server 2003 family, ASP.NET runs as part of the w3wp process using the default identity "NETWORK SERVICE". 

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 machine. In Windows 2000, Windows XP, and the Windows Server 2003 family systems, the System account also has network credentials and can access network resources as the machine account.

To configure the process to run as System, change the userName attribute in the <processModel> section of machine.config as follows:
<processModel  userName="system" password="autogenerate" �/>

Reactive Process Recycling

Reactive process recycling occurs when a process is misbehaving or 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 control the conditions that trigger a process restart by using the configuration settings described in the following table.

SettingDescription
requestQueueLimit Handles deadlock conditions. The DWORD value is set to the maximum allowed number of requests in the queue, after which the worker process is considered to be misbehaving. When the number is exceeded, a new process is launched and the requests are reassigned. The default is 5000 requests.
memoryLimit Handles memory leak conditions. The DWORD value is set to the percentage of physical memory that the worker process can consume before it is considered to be misbehaving. When that percentage is exceeded, a new process is launched and the requests are reassigned. The default is 60%.
shutdownTimeout Specifies the amount of time the worker process has to shut itself down gracefully (string value in hr:min:sec format). When the time out expires, the ASP.NET ISAPI shuts down the worker process. The default is "00:00:05".

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.

SettingDescription
timeout String value in hr:min:sec format that configures the time limit after which a new worker process will be launched to take the place of the current one. The default is Infinite, a keyword indicating that the process should not be restarted.
idleTimeout String value in hr:min:sec format that configures the amount of inactivity, after which the worker process is automatically shut down. The default is Infinite, a keyword indicating that the process should not be restarted.
requestLimit DWORD value set to the number of requests after which a new worker process will be launched to take the place of the current one. The default is Infinite, a keyword indicating that the process should not be restarted.

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 attribute in the <processModel> configuration section.

SettingDescription
logLevel Controls that process cycling events are logged to the event log. The value can be:
  • All: All process cycling events are logged.
  • None: No events are logged.
  • Errors: Only unexpected events are logged.

When a cycling event occurs, if logging is enabled for that event, the following events are written to the application event log.

Shutdown ReasonEvent Log TypeDescription
Unexpected Error The ASP.NET worker process has shut down unexpectedly.
RequestQueueLimit Error The ASP.NET worker process has been restarted because the request queue limit was exceeded.
RequestLimit Information The ASP.NET worker process has been restarted because the request limit was exceeded.
Timeout Information The ASP.NET worker process has been restarted because the time-out interval was met.
IdleTimeout Information The ASP.NET worker process has been shut down because the idle time-out interval was met.
MemoryLimitExceeded Error The ASP.NET worker process was restarted because the process memory limit was exceeded.