IIS 7.0

The release of IIS 7.0 coincides with the ten-year anniversary of the release of the first version of IIS, in Windows NT® 4.0. In 2001, four versions later, IIS 5.0 became the most prevalent Web server on the Internet, though months later it fell victim to the infamous Code Red and Nimbda worms. IIS 6.0, released in Windows Server® 2003, was a major rewrite of the server, focused entirely on improving security, reliability, and performance. Since then, IIS 6.0 has proven to be a rock-solid Web server, achieving high reliability and security track records with only a single critical security bulletin since its release (which was not exploitable remotely).

The vision for IIS 7.0 was to take the speed, reliability, and security of the IIS 6.0 codebase and turn it into a highly extensible and manageable Web server platform powerful enough to run Web applications of the future. The result is the most ambitious Microsoft Web server yet, delivering the largest number of architectural improvements in the history of IIS.
At the core of the IIS 7.0 release is a completely modular Web server, comprised of more than 40 features that can be assembled into small-footprint Web servers optimized for the desired role in your application topology. These features are built on top of a new extensibility layer that allows developers to extend or replace virtually any aspect of the server, in native code or with the Microsoft® .NET Framework. IIS 7.0 offers extensibility throughout its runtime, management, and operational features to help you build end-to-end solutions for your specific needs. On top of the core platform, IIS 7.0 tackles many of the problems associated with the manageability and operation of the server. It features a brand new configuration system that enables fully delegated management of sites and finally makes xcopy deployment of Web applications a reality. The new management APIs and diagnostic features make deployment, administration, and troubleshooting of the server significantly easier and more convenient than ever before.

Integration with ASP.NET in IIS 6.0 and IIS 7.0

Integration with ASP.NET in IIS 6.0 and IIS 7.0

 source: http://msdn.microsoft.com/en-us/magazine/cc163453.aspx

How To Use SQL Server to Analyze Web Logs

Internet Information Server/Services provides a number of formats to gather data in the form of web logs. For busy sites, these text-based flat files sometime become too much of burden to review and are ignored. A better way to review the data would make these logs a better resource for administrators and web masters.
This article describes a method to import IIS logs in World Wide Web Consortium (W3C) Extended Logging format into Microsoft SQL Server to facilitate the review of the IIS log files. The techniques provided can also be altered for other log file formats.
In W3C Extended Logging format the fields are somewhat self explanatory: data and time are just what they seem; [c-ip] is the IP address of the client; [cs-method] is the HTTP method for the request that was met; [cs-uri-stem] is the document that has been requested; [cs-uri-query] is the query string that was sent as part of the request being logged; [sc-status] is the status code returned by the server; [sc-bytes] is the number of bytes that have been returned to the user; [time-taken] is the time in milliseconds that it took for the server to complete the processing of the request; [cs(Cookie)] is the cookie, or persistent data in the request; and [cs(Referer)] is the URL of the previous site visited by the user

The logs are formatted as follows:

date time c-ip cs-method cs-uri-stem cs-uri-query sc-status sc-bytes time-taken cs(User-Agent) cs(Cookie) cs(Referrer)

The header of the log files corresponds to the fields chosen in the Properties of the Web site, on the Web Site tab, and in the case of W3C Extended Logging, the Extended Properties tab. If your web logs are already in a table in Microsoft SQL Server, it is likely because of ODBC logging. However, when you are using ODBC logging the fields are not configurable. IIS Help has instructions on setting up ODBC logging, which includes using Logtemp.sql to create the table in the expected structure.
You could use Enterprise Manager to create the table, but to make it faster and to aid in the automation of the process, instead use the following script in Query Analyzer to create the table:

CREATE TABLE [dbo].[tablename] (
[date] [datetime] NULL,
[time] [datetime] NULL ,
[c-ip] [varchar] (50) NULL ,
[cs-method] [varchar] (50) NULL ,
[cs-uri-stem] [varchar] (255) NULL ,
[cs-uri-query] [varchar] (2048) NULL ,
[sc-status] [int] NULL ,
[sc-bytes] [int] NULL ,
[time-taken] [int] NULL ,
[cs(User-Agent)] [varchar] (255) NULL ,
[cs(Cookie)] [varchar] (2048) NULL ,
[cs(Referer)] [varchar] (2048) NULL
Note that some of these fields are quite large and may not be necessary for reviewing your particular log files.
Once the table has been created, you can import the data by using the Import Wizard, mapping from the *.log file to the database and table.
Using the Wizard can be tedious, so the following can be used to expedite importing the web logs:

BULK INSERT [dbo].[tablename] FROM ‘c:\weblog.log’
Note that the bulk insert will fail when it encounters lines that start with “#”. For web logs, this includes the first four lines, as well as any other instances when the server is stopped and started, since the header lines are written when the service is restarted. The following Microsoft Knowledge Base article provides a utility and source code to remove these lines and prepare the log for the bulk insert to SQL Server: http://support.microsoft.com/kb/296093/EN-US/ FILE: PrepWebLog Utility Prepares IIS Logs for SQL Bulk Insert

Description of the time-taken field in IIS 6.0 and IIS 7.0 HTTP logging

By default, IIS logs HTTP site activity by using the W3C Extended log file format. You can use IIS Manager to select the fields to include in the log file. One of these fields is the time-taken field.
The time-taken field measures the length of time that it takes for a request to be processed. The client-request time stamp is initialized when HTTP.sys receives the first byte of the request. HTTP.sys is the kernel-mode component that is responsible for HTTP logging for IIS activity. The client-request time stamp is initialized before HTTP.sys begins parsing the request. The client-request time stamp is stopped when the last IIS response send completion occurs.
Beginning in IIS 6.0, the time-taken field typically includes network time. Before HTTP.sys logs the value in the time-taken field, HTTP.sys usually waits for the client to acknowledge the last response packet send operation or HTTP.sys waits for the client to reset the underlying TCP connection. Therefore, when a large response or large responses are sent to a client over a slow network connection, the value of the time-taken field may be more than expected.
Note The value in the time-taken field does not include network time if one of the following conditions is true:

  • The response size is less than or equal to 2 KB, and the response size is from memory.
  • TCP buffering is used.

more info: http://kbalertz.com/Feedback.aspx?kbNumber=324279

Recycling an Application Pool (IIS 6.0)

Application pools are made up of a listening and routing structure in HTTP.sys and one or more ready-to-start worker processes that are waiting to process incoming requests. In worker process isolation mode, you can configure IIS to periodically restart worker processes under certain conditions. This automatic restarting of worker processes is called recycling.

Recycling an application pool causes the WWW service to shut down all running worker processes that are serving the application pool, and then start new worker processes. Whether the WWW service starts the new worker processes before it stops the existing one depends on the DisallowOverlappingRotation property in the metabase. Recycling an application pool does not alter any state in HTTP.sys or change any configuration in the metabase.


When an application pool is serviced by more than one worker process, the recycle operation is staggered in some scenarios. Only when a worker process is recycled on demand or when all of the worker processes hit their memory limits at the same time would they be restarted simultaneously.

For information about recycling an application pool on demand, see Configuring Worker Processes for Recycling.

(sursa: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/f11b8294-cc42-4e9c-8482-6257bf3b80f2.mspx?mfr=true )

HTTP Protocol Stack (IIS 6.0)

The HTTP listener is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). IIS 6.0 uses HTTP.sys, which is part of the networking subsystem of the Windows operating system, as a core component.

Earlier versions of IIS use Windows Sockets API (Winsock), which is a user-mode component, to receive HTTP requests. By using HTTP.sys to process requests, IIS 6.0 delivers the following performance enhancements:
• Kernel-mode caching. Requests for cached responses are served without switching to user mode.
• 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.

Using HTTP.sys and the new WWW service architecture provides the following benefits:
• 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.
• 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.

How HTTP.sys Works
When you create a Web site, IIS registers the site with HTTP.sys, which then receives any HTTP requests for the site. HTTP.sys functions like a forwarder, sending the Web requests it receives to the request queue for the user-mode process that runs the Web site or Web application. HTTP.sys also sends responses back to the client.
Other than retrieving a stored response from its internal cache, HTTP.sys does not process the requests that it receives. Therefore, no application-specific code is ever loaded into kernel mode. As a result, bugs in application-specific code cannot affect the kernel or lead to system failures.
HTTP.sys provides the following services in IIS 6.0:
• Routing HTTP requests to the correct request queue.
• Caching of responses in kernel mode.
• Performing all text-based logging for the WWW service.
• Implementing Quality of Service (QoS) functionality, which includes connection limits, connection timeouts, queue-length limits, and bandwidth throttling.

How HTTP.sys Handles Kernel-Mode Queuing
When IIS 6.0 runs in worker process isolation mode, HTTP.sys listens for requests and queues those requests in the appropriate queue. Each request queue corresponds to one application pool. An application pool corresponds to one request queue within HTTP.sys and one or more worker processes.
When IIS 6.0 runs in IIS 5.0 isolation mode, HTTP.sys runs like it runs in worker process isolation mode, except that it routes requests to a single request queue.
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.

(sursa : http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a2a45c42-38bc-464c-a097-d7a202092a54.mspx?mfr=true )

Working with IIS 6.0 Application Pools – The Performance Tab

The Performance tab of IIS 6.0 application pool configuration properties contains settings that monitor the performance of the application pool and the worker processes running in it. These are the Performance configuration properties:

Shutdown worker processes after being idle for (time in minutes)
This setting limits the number of minutes that a worker process can remain idle before it will be shut down by the system.
Limit the kernel request queue (number of requests)
This setting limits the number of requests that can be queued for this application pool before 503 HTTP error messages are returned to users.
• Enable CPU monitoring
This setting activates CPU monitoring and enables the next three settings to be used.
• Maximum CPU use (percentage)
This setting specified the maximum CPU usage allowed before an action is taken.
• Refresh CPU usage number (in minutes)
This setting specifies the intervals at which the CPU usage should be checked.
• Action performed when CPU usage exceeds maximum CPU use
This setting specifies the action performed when the CPU usage is found to have exceeded the maximum CPU use. Two options are available:
1. Take No Action – IIS logs the CPU maximum usage event in the System event log but takes no corrective action.
2. Shutdown – IIS logs the event and requests that the application pool’s worker processes be recycled, based on the Shutdown Time Limit set on the Health tab.

• Maximum number of worker processes
This setting specifies the maximum number of worker processes that will be created to handle this application pool.

Notes on Shutting Down Idle Worker Processes
Although worker processes start on demand based on incoming requests and thus resources are allocated only when necessary, worker processes don’t free up the resources they use until they are shut down. In the default configuration, worker processes are shut down after they have been idle for 20 minutes. This ensures that any physical or virtual memory used by the worker process is made available to other processes running on the server, which is especially important if the server is busy.
Shutting down idle worker processes is a good idea in most instances, and if system resources are at a premium you might even want idle processes shut down sooner than 20 minutes. For example, on a moderately busy server with many configured sites and applications where there are intermittent resource issues, reducing the idle time-out could resolve the problems of resource availability.
Keep in mind though that shutting down idle worker processes can have unintended consequences. For example, on a dedicated server with ample memory and resources, shutting down idle worker processes clears cached components out of memory. These components must be reloaded into memory when the worker process starts and requires them, which might make the application seem unresponsive or sluggish.

Notes on Limiting Request Queues
When hundreds or thousands of new requests pour into an application pool’s request queue, the IIS server can become overloaded and overwhelmed. To prevent this from occurring, you can limit the length of the application pool request queue. Once a queue limit is set, IIS checks the queue size each time before adding a new request to the queue. If the queue limit has been reached, IIS rejects the request and sends the client an HTTP Error 503: Service Unavailable message.
Requests that are already queued remain queued even if you change the queue limit to a value that is less than the current queue length. The only consequence here would be that new requests wouldn’t be added to the queue until the current queue length is less than the queue limit.
The default limit for an application pool is 4000 requests. On a moderately sized server with a few application pools configured, this might be a good value. However, on a server with multiple CPUs and lots of RAM, this value might be too low. On a server with limited resources or many application pools configured, this value might be too high. Here you might want to use a formula of Memory Size in Megabytes x Number of CPUs x 10 divided by Number of Configured Application Pools to determine what the size of the average request queue should be. This is meant to be a guideline to give you a starting point for consideration and not an absolute rule. For example, on a server with two CPUs, 1024 MB of RAM, and twenty configured application pools, the size of the average request queue limit would be around 1,000 requests. You might have some application pools configured with request queue limits of 750 and others with request queue limits of 1,250. However, if the same server had only one configured application pool, you probably wouldn’t configure a request queue limit of 10,000.
Typically, you’ll want to set a value to at least 90 percent. However, to ensure that worker processes are recycled only when they’re blocking other processes, you should set the value to 100 percent.

Notes on CPU Monitoring
Typically, you’ll want to set a value to at least 90 percent. However, to ensure that worker processes are recycled only when they’re blocking other processes, you should set the value to 100 percent.
In most cases you won’t want to check the CPU usage more frequently than every five minutes. If you monitor CPU usage more frequently, you might waste resources that could be better used by other processes.

Notes on Configuring Multiple Worker Processes for Application Pools
Multiple worker processes running in their own context can share responsibility for handling requests for an application pool. This configuration setting is referred to as a Web Garden. When you define a Web Garden, each new request is assigned to a worker process according to the round-robin load balancing technique.
If a single application is placed in an application pool serviced by multiple worker processes, any and all worker processes available will handle requests queued for the application. This is a multiple-worker-process-to-single-application configuration, and it is best used when you want to improve the application’s request handling performance and reduce any possible contention for resources with other applications. In this care the application might have heavy usage during peak periods and moderate-to-heavy usage during other times, or individuals using the application might have specific performance expectations that must be met.
If multiple applications are placed in an application pool serviced by multiple worker processes, any and all worker processes available handle the requests queued for any applicable application. This is a multiple-worker-process-to-multiple-application configuration, and it is best used when you want to improve request handling performance and reduce resource contention for multiple applications but don’t want to dedicate resources to any single application. In this case the various applications in the application pool might have different peak usage periods or might have varying resource needs.
It’s important to note that worker processes aren’t started automatically and don’t use resources until they are needed. Rather, they are started as necessary to meet the demand based on incoming requests. For example, if you configure a maximum of five worker processes for an application pool, there may be at any given time from zero to five worker processes running in support of applications placed in that application pool.
You also need to keep in mind that when you assign multiple worker processes to a busy application pool that each worker process sues server resources when it’s started and might affect the performance or applications in other application pools. Adding worker processes won’t resolve latency issues due to network communications or bandwidth, and it can reduce the time it takes to process requests only if those requests were queued and waiting and not being actively processed. A poorly engineered application will still respond poorly, and at some point you’d need to look at optimizing the application code for efficiency and timeliness.

How ASP.NET Works with IIS 6.0 (IIS 6.0)

How ASP.NET Works with IIS 6.0 (IIS 6.0)

If you run your ASP.NET applications in IIS 6.0, you obtain a significant advantage over running your ASP.NET applications in IIS 5.0. For example, in IIS 5.0, you cannot isolate individual applications into their own worker processes; hence, if one ASP.NET application fails, it can affect all the other applications. IIS 6.0, however, provides a new architecture that allows you to isolate your ASP.NET applications without incurring a performance penalty.

Before you run ASP.NET applications on IIS 6.0, be sure that you understand how ASP.NET works with the two IIS 6.0 isolation modes. When running in IIS 5.0 isolation mode, ASP.NET uses its own request processing model and configuration settings in the Machine.config file — just as it does when ASP.NET runs on IIS 5.x. When running in worker process isolation mode, ASP.NET disables its own request processing model and uses the new worker process architecture of IIS 6.0.

Important: The version of ASP.NET that is included with WindowsServer2003 is not available with the Microsoft® Windows® XP 64-Bit Edition and the 64-bit versions of Windows Server 2003. For more information, see Features unavailable on 64-bit versions of the Windows Server 2003 family in Help and Support Center for Windows Server 2003.

ASP.NET Request Processing Model
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.

In almost all situations, if your ASP.NET applications are running on Windows Server 2003, configure them to run in worker process isolation mode. However, if your application has compatibility issues in this mode — for example, if your application depends upon read raw ISAPI data filters — you can change your configuration to run IIS 6.0 in IIS 5.0 isolation mode.

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

When multiple versions of the .NET Framework are installed on a computer that uses IIS 6.0, you might encounter the following error message in the Application Event log:

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

(sursa http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/f1a39358-5ab8-4dc1-a60d-eedea7360780.mspx?mfr=true )

Process Model Configuration

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 settings are exposed in the root configuration file for the computer, Machine.config. The configuration section is named
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 by default in IIS6 native mode (Worker Process Isolation Mode).

<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 IIS5 Isolation mode is configured on the Windows Server 2003 family, the ASP.NET worker process would run 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 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
section of machine.config as follows:

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.

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

Setting Description
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 configuration section.

Setting Description
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 Reason Event Log Type Description
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.

Enabling Web Gardens

The process model helps enable scalability on multiprocessor computers by distributing the work to several processes, one per CPU, each with processor affinity set to its CPU. This eliminates cross-processor lock contention and is ideal for large SMP systems. This technique is called Web gardening. The configuration settings for enabling Web gardens are listed in the following table. Note that these settings take effect only after a server is restarted. IIS must be cycled in order for this change to take place.

Setting Description
webGarden Controls CPU affinity. True indicates that processes should be affinitized to the corresponding CPU. The default is False.
cpuMask Specifies which processors on a multiprocessor server are eligible to run ASP.NET processes. The cpuMask value specifies a bit pattern that indicates the CPUs eligible to run ASP.NET threads. ASP.NET launches one worker process for each eligible CPU. If webGarden is set to false, cpuMask is ignored and only one worker process will run regardless of the number of processors in the machine. If webGarden is set to true, ASP.NET launches one worker process for each CPU that corresponds to a set bit in cpuMask. The default value of cpuMask is 0xffffffff.

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 statics are per process, not per computer.
Caching is per process, not per computer.

Section Summary
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 overall availability of Web applications.
The settings are exposed in the root configuration file for the computer’s Machine.config file. On Windows 2000 and Windows XP, the process model is enabled by default. On the Windows Server 2003 family, it is not.
The process model supports two types of recycling: reactive and proactive. Reactive process recycling occurs when a process is misbehaving or unable to serve requests. Proactive process recycling restarts the worker process periodically, even when the process may be healthy.
The process model can write events to the Windows event log when process cycling occurs. This is controlled by the log-level attribute in the configuration section.
The process model helps enable scalability on multiprocessor computers by distributing the work to several processes, one per CPU, each with processor affinity set to its CPU. This technique is called Web gardening.

ASP.NET Internals – IIS and the Process Model

Microsoft Active Server Pages, also known as ASP, since its first release in late 1996 provided web developers with a rich and complex framework for building web applications. As years passed its infrastructure evolved and improved so much that what is now known as ASP.NET is no longer something which resembles its predecessor. ASP.NET is a framework for building web applications, that is, applications that run over the web, where the client-server paradigm is represented mostly by a browser forwarding requests for resources of different kinds to a web server. Before the advent of dynamic server-side resource generation techniques like CGI, PHP, JSP and ASP, all web servers had to do was accept client’s requests for static resources and forward them to the requestor. When dynamic technologies started to grow up web servers became invested of greater responsibility, since they had to find a way to generate those dynamic resources on their side and return the result to the client, a task they were not formerly built for.
From a bird’s eye view, the interaction between client and server is very simple. Communications over the web occur via HTTP (Hyper Text Transfer Protocol), an application level protocol which relies on TCP and IP to transmit data between two nodes connected to the heterogeneous network known as World Wide Web.
Each dynamic server-side technology essentially leans on a particular web server implementation, and ASP.NET is tightly coupled with Microsoft’s Internet Information Server, aka IIS.
Different servers chose different ways to generate and serve dynamic resources and what we’re going to examine is how IIS does that, together with the path a request follows once on the server and back to the client.

IIS and ISAPI Extensions
As mentioned, static resources needn’t to be processed by the server; once a request for such a resource arrives, the server just retrieves its contents from the file system and sends it back to the client as a stream of byte flowing on the HTTP protocol. Static resources can be images, Javascript files, css style sheets or plain old html pages. It’s clear that the server needs to know how to distinguish between static and dynamic resource, whereas the second need to be processed somehow and not just sent back to the client. That’s where ISAPI extensions appear, where ISAPI stands for Internet Server Application Programming Interface. ISAPI extensions are modules implemented as plain old Win32 .dll, on which IIS relies to process specific resources. Mappings between ISAPI extensions and files are configured via the IIS snap-in and stored in the IIS metabase, where each file extension can be associated with a particular ISAPI extension, that is, when a request for such a file arrives, IIS handles it to the corresponding ISAPI extension, confident that it will be able to handle it.

ISAPI extensions obviously need to respect a common interface through which they can be called by IIS and provided the necessary data to elaborate the request and generate a response.

The .asp extension is mapped to the asp.dll ISAPI extension; at the time of ASP this component was in charge of performing all the tasks required to generate a response, that is, collecting information about the request, made available into the ASP page via the Request, Response and other common ASP intrinsic objects, parsing and executing the ASP page and returning the resulting HTML.

Actually, that was a big improvement compared to a technology like CGI, but ASP.NET takes this approach much further and introduces abstractions which totally shield the developers from having to care about what happens at this stage.

When installed, ASP.NET configures IIS to redirect requests for ASP.NET specific files to a new ISAPI extension called aspnet_isapi.dll. What this extension does is somewhat different then the former asp.dll extension, which was essentially responsible just for parsing and executing the requested ASP page. The steps taken by a generic ISAPI module to process a request are totally hidden from IIS, therefore ISAPI extension may follow different paradigms in order to process requests.

Table 1: IIS Application Mappings for aspnet_isapi.dll

Extension Resource Type
.asax ASP.NET application files. Usually global.asax.
.ascx ASP.NET user control files.
.ashx HTTP handlers, the managed counterpart of ISAPI extensions.
.asmx ASP.NET web services.
.aspx ASP.NET web pages.
.axd ASP.NET internal HTTP handlers.

As well as the file extensions listed in Table 1, the ASP.NET ISAPI extension manages other file extensions which are usually not served to web browsers, like Visual Studio project files, source code files and config files, for example.

The ASP.NET Process Model
So far we’ve seen that when a request for an ASP.NET file is picked up by IIS, it is passed to the aspnet_isapi.dll, which is the main entry point for ASP.NET related processing. Actually, what the ISAPI extension does depends sensibly on the version of IIS available on the system, and thus the process model, which is the sequence of operations performed by the ASP.NET runtime to process the request and generate a response, may vary quite a bit.
When running under IIS 5.X, all ASP.NET-related requests are dispatched by the ISAPI extension to an external worker process called aspnet_wp.exe. The ASP.NET ISAPI extension, hosted in the IIS process inetinfo.exe, passes the control to aspnet_wp.exe, along with all the information concerning the incoming request. The communication between the two is performed via named pipes, a well known mechanism for IPC (Inter Process Communication). The ASP.NET worker process performs a considerable number of tasks, together with the ISAPI extension. They are the main authors of all the stuff that happens under the hoods of an ASP.NET request. To introduce a topic which will be discussed later, take note of the fact that each web application, corresponding to a different virtual directory hosted on IIS, is executed in the context of the same process, the ASP.NET worker process. To provide isolation and abstraction from the execution context the ASP.NET model introduces the concept of Application Domains, in brief AppDomains. They can be considered as lightweight processes.
If running under IIS 6, on the other side, the aspnet_wp.exe process is not used, in favour of another process called w3wp.exe. Furthermore, inetinfo.exe is no longer used to forward HTTP requests to ISAPI extensions, although it keeps running for serving other protocols requests. A lot of other details change compared to the process model used by previous versions of IIS, although IIS 6 is capable of running in compatibility mode and emulate the behavior of its predecessor. A big step forward, compared to the process model used when running on top of IIS 5, is that incoming requests are in the former handled at a lower – Kernel – level and then forwarded to the correct ISAPI extension, thereby avoiding inter process communication techniques which may represent an expensive operation under a performance and resource consumption point of view. We’ll delve deeper into this topic in the following paragraphs.

IIS 5.0 Process Model
This is the default process model available on Windows 2000 and XP machines. As mentioned it consists in the IIS inetinfo.exe process listening by default on the TCP port 80 for incoming HTTP requests and queuing them into a single queue, waiting to be processed. If the request is specific to ASP.NET, the processing is delegated to the ASP.NET ISAPI extension, aspnet_isapi.dll. This, in turn, communicates with the ASP.NET worker process, aspnet_wp.exe via named pipes and finally is the worker process which takes care of delivering the request to the ASP.NET HTTP runtime environment. This process is graphically represented in Figure 2.


The IIS 5.0 Process Model

Figure 2: The IIS 5.0 Process Model

In Figure 2 is represented an additional element we didn’t mention yet, the ASP.NET HTTP Runtime Environment. It’s not topic of this article and will eventually be explained in a follow up article, but for the sake of this discussion the HTTP Runtime Environment can be considered as a black box where all the ASP.NET specific processing takes place, all the managed code lives and developers can actually put their hands on, from the HttpRuntime straight to the HttpHandler who will finally process the request and generate the response. This is even referred to as the ASP.NET Pipeline or HTTP Runtime pipeline.

One of the interesting points of this process model is that all the requests, once handled by the ISAPI extension, are passed to the ASP.NET worker process. Only one instance of this process is active at a time, with one exception, discussed later. Therefore all ASP.NET web applications hosted on IIS are actually hosted inside the worker process, too. However, this doesn’t mean that all the applications are run under the same context and share all their data. As mentioned, ASP.NET introduces the concept of AppDomain, which is essentially a sort of managed lightweight process which provides isolation and security boundaries. Each IIS virtual directory is executed in a single AppDomain, which is loaded automatically into the worker process whenever a resource belonging to that application is requested for the first time. Once the AppDomain is loaded – that is, all the assemblies required to satisfy that request are loaded into the AppDomain – the control is actually passed to the ASP.NET pipeline for the actual processing. Multiple AppDomains can thus run under the same process, while requests for the same AppDomain can be served by multiple threads. However, a thread doesn’t belong to an AppDomain and can serve requests for different AppDomains, but at a given time a thread belongs to a single AppDomain.

For performance purposes the worker process can be recycled according to some criteria which can be specified declaratively in the machine.config file placed in the directory C:\windows\microsoft.net\Framework\[framework version]\CONFIG. These criteria are the age of the process, number of requests served and queued, time spent idle and consumed memory. Once one of the threshold value of these parameters is reached, the ISAPI extension creates a new instance of the worker process, which will we used from then on to serve the requests. This is the only time when multiple copies of the process can be running concurrently. In fact, the old instance of the process isn’t killed, but it is allowed to terminate serving the pending requests.

IIS 6.0 Process Model
The IIS 6 process model is the default model on machines running Windows 2003 Server operating system. It introduces several changes and improvements over the IIS 5 process model. One of the biggest changes is the concept of application pools. On IIS 5.X all web applications, that is, all AppDomains, were hosted by the ASP.NET worker process. To achieve a finer granularity over security boundaries and personalization, the IIS 6 process model allows applications to run inside different copies of a new worker process, w3wp.exe. Each application pool can contain multiple AppDomains and is hosted in a single copy of the worker process. In other words, the shift is from a single process hosting all applications to multiple processes hosting each an application pool. This model is also called the worker process isolation mode.

Another big change from the previous model is the way IIS listens for incoming requests. With the IIS 5 model, it was the IIS process, inetinfo.exe, who was listening on a specific TCP port for HTTP requests. In the IIS 6 architecture, incoming requests are handled and queued at kernel level instead of user mode via a kernel driver called http.sys; this approach has several advantages over the old model and is called kernel-level request queuing.

The IIS 6.0 process model

Figure 3: The IIS 6.0 process model

Figure 3 illustrates the principal components taking part in the request processing when using the II 6 model. Once a request arrives the kernel level device driver http.sys routes it to the right application pool queue. Each queue belongs to a specific application pool, and thus to a specific copy of the worker process, which next receives the request from the queue. This approach highly reduces the overhead introduced by named pipes used in IIS 5 model since no inter process communication is taking place, but the requests are headed to the worker process directly from the kernel level driver. This has many advantages concerning reliability, too. Since running in kernel mode, the request dispatching isn’t influenced by crashes and malfunctions happing at user level, that is, in the worker processes. Thereby, even if a worker process crashes, the system is still capable of accepting incoming requests and eventually restarts the crashed process.

It’s the worker process who is in charge of loading the ASP.NET ISAPI extension, which, in turn, loads the CRL and delegates all the work to the HTTP Runtime.

The w3wp.exe worker process, differently from the aspnet_wp.exe process used in IIS 5 model, isn’t ASP.NET specific, and is used to handle any kind of requests. The specific worker process then decides which ISAPI modules to load according to the type of resources it needs to serve.

A detail not underlined in Figure 3 for simplicity reasons is that incoming requests are forwarded from the application pool queue to the right worker process via a module loaded in IIS 6 called Web Administration Service (WAS). This module is responsible for reading worker process – web application bindings from the IIS metabase and forwarding the request to the right worker process.

(sursa: http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx)

Running multiple versions of the Framework in ASP.NET

Like any good technology, ASP.NET continues to evolve as new versions are released. But, like anything else, this brings with it a number of considerations.

Microsoft has done a great job of allowing multiple versions of the framework to run side by side. Version v1.0, v1.1 and v2.0 can all run together at the same time on the same server. Each site, or even a vdir (Virtual Directory) within a site can have its own version of the framework installed. Simply install the framework version on your server and it will be available to you. The install itself is quite small, for example the v2.0 download is 22MB.

The Microsoft homepage for the .NET Framework is:

There are a couple gotchas to consider with running multiple versions of the framework side by side. First, let’s dig into IIS a bit. Following is a snapshot of Windows Task Manager on an IIS5 (Windows 2000) server:


Notice the 3 processes called aspnet_wp.exe. There is one per version of the framework. (v1.0, v1.1 and v2.0) If a process for a particular version of the framework doesn’t exist, as soon as it’s needed, a new process will be spun up. This allows multiple versions of the framework to live beside each other in IIS5. No effort, no pain . . . it just works.

Now consider the following IIS6 (Windows Server 2003) screenshot:

Notice that there aren’t any aspnet_wp.exe processes anymore, but there are w3wp.exe processes instead. IIS6 was an impressive upgrade that brought with it some new concepts. One key new concept is Application Pools. A system administrator is able to create groups of sites and place each site in its own group. Whenever a site needs to run, a w3wp.exe process will start for its application pool if it hasn’t already started. This brings with it a number of welcome security, performance and management advantages. You are now able to specify your own Identity User which can be unique per Application Pool.

In IIS6, the aspnet_wp.exe process is done away with, and the work that it did is now done within each w3wp.exe process. This has the same advantages I mentioned previously, but it has one big gotcha!

You cannot run more than one version of the framework in the same application pool in IIS6.

While multiple versions of the framework can co-exist on the same server, they can’t co-exist in the same process. If you attempt to run multiple versions of the framework at the same time in the same process, the 2nd version that tries to run will fail with the following error:

Server Application Unavailable
The web application you are attempting to access on this web server is currently unavailable. Please hit the “Refresh” button in your web browser to retry your request.

Administrator Note: An error message detailing the cause of this specific request failure can be found in the application event log of the web server. Please review this log entry to discover what caused this error to occur.

You will also receive Event ID 1062 in Event Viewer that says:

“It is not possible to run two 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.”

What to do

Fortunately, the solution is easy enough. Simply create a new application pool and move the site that you will be upgrading to that pool. You can even base it off of the existing one if you don’t have the password memorized for the existing one. This is all done within IIS. Once you have placed the site or vdir in its own application pool, then you are ready to upgrade to the new framework version.

(sursa: http://blogs.orcsweb.com/scott/)