ASP.Net Process Model (IIS 6.0)

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

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

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

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 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 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
Element configuration section.

Reference

ASP.Net with IIS 6.0

When ASP.NET is enabled on a server running Windows Server 2003, the ASP.NET request processing model depends on the application isolation mode in which IIS 6.0 is running. The preferred application isolation mode for IIS 6.0 is worker process isolation mode, which enables you to use application pools, worker process recycling, and application pool health monitoring. When IIS 6.0 is running in worker process isolation mode, ASP.NET uses the IIS 6.0 request processing model settings.

If you configure IIS 6.0 to run in IIS 5.0 isolation mode, ASP.NET runs in its own request processing model, Aspnet_wp.exe, and uses its own configuration settings for process configuration, which are stored in the Machine.config configuration file. When your server is running in IIS 5.0 isolation mode, the ASP.NET ISAPI extension implements a request processing model that is similar to worker process isolation mode and contains worker process management capabilities similar to those provided by the WWW service. ASP.NET also provides recycling, health monitoring, and processor affinity.

When ASP.NET is installed on servers running Windows XP or Windows 2000 Server, ASP.NET runs in IIS 5.1 or IIS 5.0, respectively, and runs in the Aspnet_wp.exe process by default. The ASP.NET request processing model provides process recycling, health detection, and support for affinities between worker processes and particular CPUs on a server with multiple CPUs.

When different versions of ASP.NET share the same application pool

"It is not possible to run different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process."

This error occurs when more than one version of ASP.NET is configured to run in the same process. Different versions of the .NET Framework and run time cannot coexist side by side within the same process. Therefore, an ASP.NET application that uses one version of the run time must not share a process with an application that uses a different version. This error commonly occurs when two or more applications are mapped to different versions of ASP.NET but share the same application pool.

Application Pools & Services in IIS 6

When you run IIS 6.0 in worker process isolation mode, you can separate different Web applications and Web sites into groups known as application pools. An application pool is a group of one or more URLs that are served by a worker process or set of worker processes. Any Web directory or virtual directory can be assigned to an application pool.

Every application within an application pool shares the same worker process. Because each worker process operates as a separate instance of the worker process executable, W3wp.exe, the worker process that services one application pool is separated from the worker process that services another. Each separate worker process provides a process boundary so that when an application is assigned to one application pool, problems in other application pools do not affect the application. This ensures that if a worker process fails, it does not affect the applications running in other application pools.
Reference

IIS 6.0 Services:
IIS 6.0 offers four Internet services (WWW Service, FTP, SMTP, NNTP) that you can use to create sites or virtual servers, configure properties and security settings, and set up components to customize your system.

When you install IIS 6.0 on a computer that does not contain an earlier version of IIS, IIS 6.0 automatically installs the following two services:
1. The WWW service, which hosts Internet and intranet content
2. The IIS Admin service, which manages the IIS Metabase

You can also choose to install one or more of the following services:
1. The FTP service for hosting sites from which users can upload and download files
2. The NNTP service for hosting discussion groups
3. The SMTP service for sending and receiving e-mail messages

Reference: IIS 6 Services

World Wide Web Publishing Service:
The World Wide Web Publishing Service (WWW service) provides Web publishing for IIS, connecting client HTTP requests to Web sites running on an IIS-based Web server. The WWW service manages and configures the IIS core components that process HTTP requests. These core components include the HTTP protocol stack (HTTP.sys) and the worker processes.

IIS Admin Service:
IIS Admin service is a Windows Server 2003 service that manages the IIS metabase. The metabase stores IIS configuration data in a plaintext XML file that you can read and edit by using common text editors. IIS Admin service makes metabase data available to other applications, including the core components of IIS, applications built on IIS, and applications that are independent of IIS, such as management or monitoring tools.

HTTP Protocol Stack and Worker Processes

HTTP Protocol Stack (HTTP.sys)

1. Kernel-mode caching. Requests for cached responses are served without switching to user mode
2. Kernel-mode request queuing. Requests cause less overhead in context switching, because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up
3. When a worker process fails, service is not interrupted; the failure is undetectable by the user because the kernel queues the requests while the WWW service starts a new worker process for that application pool
4. Requests are processed faster because they are routed directly from the kernel to the appropriate user-mode worker process instead of being routed between two user-mode processes

Reference

Worker Processes (IIS 6.0)

A worker process is user-mode code whose role is to process requests, such as processing requests to return a static page, invoking an ISAPI extension or filter, or running a Common Gateway Interface (CGI) handler. In both application isolation modes, the worker process is controlled by the WWW service. However, in worker process isolation mode, a worker process runs as an executable file named W3wp.exe, and in IIS 5.0 isolation mode, a worker process is hosted by Inetinfo.exe.

Worker processes use HTTP.sys to receive requests and to send responses by using HTTP. Worker processes also run application code, such as ASP.NET applications and XML Web services. You can configure IIS to run multiple worker processes that serve different application pools concurrently. This design separates applications by process boundaries and helps achieve maximum Web server reliability.

Reference

Application Isolation modes in IIS 6.0

IIS 6.0 have two types of isolation mode:

1. Worker process isolation mode
2. IIS 5.0 isolation mode

In IIS 6.0, application isolation is configured differently for each of the two IIS application isolation modes. Both modes rely on the HTTP protocol stack (also referred to as HTTP.sys) to receive Hypertext Transfer Protocol (HTTP) requests from the Internet and return responses. HTTP.sys resides in kernel mode, where operating system code, such as device drivers, runs. HTTP.sys listens for, and queues, HTTP requests. For more information about HTTP.sys, see HTTP Protocol Stack.

The new request-processing architecture and application isolation environment enables individual Web applications, which always run in user mode, to function within a self-contained worker process. A worker process is user-mode code whose role is to process requests, such as returning a static page or invoking an Internet Server API (ISAPI) extension or filter. Worker processes use HTTP.sys to receive requests and send responses over HTTP. A worker process is user-mode code whose role is to process requests, such as returning a static page or invoking an Internet Server API (ISAPI) extension or filter. Worker processes use HTTP.sys to receive requests and send responses over HTTP. For more information about worker processes, see Worker Processes.

Worker process isolation mode:
Process can belong to either Kernel mode or user mode. Kernel mode runs all operating system related code as well as device drivers etc. HTTP.sys runs as kernel mode process. This process always listens to client requests. It also uses cache to store the responses. When ever request arrives at HTTP.sys, it first checks in cache. if response is already present then HTTP.sys will send back the response. otherwise it will send the request in queue. Here since IIS 6 is running under worker process isolation mode, each application pool has its separate request queue. An application pool corresponds to one request queue within HTTP.sys and one or more worker processes.




IIS 5 isolation mode:
This mode of request processing is exactly similar to worker process isolation mode. The only difference is here HTTP.sys have only one request queue instead of having separate request queues. When a server is working in IIS 5.0 isolation mode, application pools, recycling, and health monitoring features are unavailable.




Get more details on isolation modes in IIS 6

If a defective application causes the user-mode worker process to terminate unexpectedly, HTTP.sys continues to accept and queue requests, provided that the WWW service is still running, queues are still available, and space remains in the queues.

When the WWW service identifies an unhealthy worker process, it starts a new worker process if outstanding requests are waiting to be serviced. Thus, although a temporary disruption occurs in user-mode request processing, an end user does not experience the failure because TCP/IP connections are maintained, and requests continue to be queued and processed.

Reference

Introduction to IIS 6 and Changes in IIS 6 from earlier versions

IIS 6.0 has been totally re-designed with a new request processing architecture that has the benefits of high isolation without incurring the out-of-process cost, as well as much higher levels of reliability and scalability.


IIS 6.0 runs a server in one of two distinct request processing models, called application isolation modes. Application isolation is the separation of applications by process boundaries that prevents one application or Web site from affecting another and reduces the time that you spend restarting services to correct problems related to applications.

Changes in IIS 6.0 from earlier versions of IIS:

1. IIS 6.0 uses different application request processing model. Since IIS 6.0 can work under two different isolation modes, it can have two different processes. If IIS 6.0 is running under worker process isolation mode then IIS 6.0 will run under w3wp.exe. If IIS 6.0 is running under IIS 5 isolation mode with in process isolation then it will run under inetinfo.exe. If IIS 6.0 is running with out-of-process request processing then it will run under dllhost.exe. For more details about in-process & out-of-process
2. IIS 6.0 uses XML for metabase configurations. Earlier versions were using binary instead of XML
3. IIS 6.0 uses HTTP.sys instead of TCP/IP kernel (Windows Socket APIs)
4. It also supports .Net passport support for security

Internet Information Services (IIS) 5: Isolation modes and Request Processing Architecture

Internet Information Services 5.0 enables you to create and manage Web sites. It is the name given to the web server that is built into Microsoft Windows Server products such as Windows NT 4.0, Windows 2000, and Windows 2003 server. IIS is a high performance web server that is built and optimized to deliver interactive web server applications for eCommerce and other uses.IIS is available in different versions. We will look IIS 6.0 & IIS 7.0

Before looking at the architecture of IIS 6.0, lets have a look at the different isolation mode & process level view of IIS 5.

IIS 5 runs in three different isolation modes:

1. In-process

2. Pooled

3. Out of process

In-process isolation mode: In this mode, all the applications run in the same process as that of the Web server (inetinfo.exe)

Pooled isolation mode:The IIS 5.0 default mode is Pooled, in which the Web server (Inetinfo.exe) runs in its own process and all other applications will run in one single-pooled process (dllhost.exe).

Out of Process isolation mode: You can set high-priority applications to run as Isolated, which creates another instance of dllhost.exe. Even though this out-of-process isolation allows you to increase the fault-tolerance of your Web server, it is slow in terms of performance. In out of process isolation mode separate dllhost.exe is created. Each dllhost.exe file runs high priority applications.

Request Processing in IIS 5.0:

Processes runs in two modes: Kernel mode & user mode. Following diagram illustrates how request processing are handled in IIS 5.0. Client Request comes to server. These requests basically are HTTP requests. Winsock control always listens to client requests using Windows Socket APIs. As soon as new HTTP requests arrives it forwards it to IIS web server i.e. inetinfo.exe process. (overhead is context switching and hence performance degradation). Now inetinfo.exe will take care of entire processing. The response will be again given back to client using winsock control only.