New Request Processing Architecture

   

Web site and application code is increasingly complex. Custom applications and Web sites hosted in customer environments might contain some imperfect code. Therefore, hosting processes need to be active managers of the run-time environment by automatically detecting memory leaks, access violations, and other errors. When these conditions occur, the underlying architecture needs to be fault tolerant, actively recycle or restart processes as necessary, and continue to queue requests , without interrupting the end user experience.

To provide this robust and actively managed run time, IIS 6.0 provides kernel-level request queuing: this is a new application isolation environment with active process management, known as worker process isolation mode. IIS 5.0 was designed to have one process, Inetinfo.exe, function as the main Web server process, which could farm out requests to one or more out-of-process applications (dllhost.exe). In comparison, IIS 6.0 has been redesigned into two new components that use a new kernel-mode driver. This allows IIS to parse out core Web server code from application-handling code. These two new components are the following:

  • HTTP.sys.

    A kernel-mode HTTP listener

  • WWW Service Administration and Monitoring component.

    A user-mode configuration and process manager

All Web application processing, including loading of Internet Server Application Programming Interface (ISAPI) filters and extensions, as well as authentication and authorization, is done by a new WWW service DLL. This DLL is loaded into one or more host processes called worker processes , which service requests for application pools in HTTP.sys. The worker process executable is named w3wp.exe.For more information on how worker processes interact with IIS 6.0, see the upcoming section "Worker Process Isolation Mode." An application pool corresponds to one request queue within HTTP.sys and to one or more worker processes. An application pool can serve requests for one or more unique Web applications. These Web applications are assigned to the application pool based on their URLs. Multiple application pools can operate at the same time. For more information about application pools, see the section "Worker Process Isolation Mode."

Note

Preliminary testing has shown a gain of more than 100 percent throughput over previous releases on a benchmark using an eight-processor server. This gain is a result of the new request processing architecture and scalability improvements in the Web application server.


HTTP.sys

In IIS 6.0, HTTP.sys listens for requests and places each request in the appropriate queue. Each request queue corresponds to one application pool. Because no third-party code runs in HTTP.sys, it cannot be affected by failures in user-mode code that normally affect the status of the Web service.

If something causes the user-mode request processing infrastructure to terminate, HTTP.sys continues to accept and queue requests, provided the WWW service is still up and running. HTTP.sys continues to accept requests and place them in the appropriate queues until no queues are available, no space is left on the queues, or the Web service has been shut down.

Once the WWW service notices the failed worker process, it starts a new worker process if requests for the worker process's application pool are still waiting to be serviced. Thus, while there might be a temporary disruption in user-mode request processing, an end user does not experience the failure because requests continue to be accepted and queued.

WWW Service Administration

Another key portion of the new IIS 6.0 architecture is the functionality in the WWW Service Administration and Monitoring component. The WWW Service Administration and Monitoring component makes up a core portion of the WWW service, where, as in HTTP.sys, critical IIS 6.0 services reside and third-party code is never loaded.

The WWW Service Administration and Monitoring component is responsible for two main areas: configuration and process management. At initialization time, the request process manager portion of WWW service reads metabase information and initializes the HTTP.sys namespace routing table with one entry for each application. Each entry contains information that routes the URLs mapped to an application pool to that specific application pool.

These preregistration steps inform HTTP.sys that there is an application pool that responds to requests in this part of the namespace and that HTTP.sys can request that a worker process be started for the application pool if there is demand. All preregistrations are done before HTTP.sys can begin to route requests to processes. As application pools and new applications are added, the Web service configures HTTP.sys to accept requests for the new URLs, sets up the new request queues for the new application pools, and indicates where the new URLs should be routed.

In the request process management role, the WWW Service Administration and Monitoring component is responsible for controlling the lifetime of the worker processes that process the requests. This includes determining the following:

  • When to start a worker process

  • When to recycle a worker process

  • When to restart a worker process if it is unable to process any more requests (becomes blocked)


   
Top


Introducing Microsoft Windows Server 2003
Introducing Microsoft Windows Server(TM) 2003
ISBN: 0735615705
EAN: 2147483647
Year: 2005
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net