IIS 5.0 Page Processing- isolation mode:
- IIS inetinfo.exe is a process by default which listens for incoming HTTP requests on TCP port 80. It will queue all the Http Requests which are waiting to be processed into a single queue.
- Depending on the request type, it delegates to corresponding ISAPI Extension. I.e. if the request is specific to ASP.NET, the processing is delegated to the ASP.NET ISAPI extension, aspnet_isapi.dll.
ISAPIextensions are modules implemented as plain old Win32 .dll, on which
IISrelies to process specific resources. Mappings between
ISAPIextensions (dll’s) and files are configured via the
IISsnap-in and stored in the
IISmetabase, where each file extension can be associated with a particular
ISAPIextension, that is, when a request for such a file arrives,
IIShandles it to the corresponding
ISAPIextension, confident that it will be able to handle it.
- When installed,
IISto redirect requests for
ASP.NETspecific files to a new
aspnet_isapi.dll. What this extension does is somewhat different, which was not only essentially responsible just for parsing and executing the requested
ASPXpage. The steps taken by a generic
ISAPImodule to process a request are totally hidden from
ISAPIextension may follow different paradigms in order to process request.
ASP.NET application files. Usually global.asax.
ASP.NET user control files.
HTTP handlers, the managed counterpart of ISAPI extensions.
ASP.NET web services.
ASP.NET web pages.
ASP.NET internal HTTP handlers.
- This ASPNET_ISAPI.dll in turn, communicates with the ASP.NET worker process i.e. 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.
- 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.
- Here it is the right place to discuss that all the requests which are specific to ASP.NET are 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. Therefore all ASP.NET web applications hosted on IIS are actually hosted inside the worker process. This doesn’t mean that all the applications are run under same context and share their data. The logical seperation happens inside 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. Here 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.
- Some Times for boosting the performance, the worker process is recycled according to the some criteria which is specified in the machine.config file. These criteria are the age of the process, number of requests it should serve, time spent idle and consumed memory. Once one of the threshold value of these parameters is reached, the ISAPI extension creates the new instance of the worker process, which will be used to serve the requests from then. This is the only time when multiple objects of worker process 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 Page Processing- worker process isolation mode
Contrast to IIS 5.0 model, 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.
- In HTTP.sys, the HTTP requests are queued based on url’s. Some set of url’s are grouped into an application pool & served by separate worker process-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.
Contrast to IIS 5.0,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.
- 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.
- In short it is, 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.
- Use multiple application pools when you want to help ensure that applications and Web sites are confidential and secure. For example, an enterprise organization might place its human resources Web site and its finance Web site on the same server, but in different application pools. Likewise, an ISP that hosts Web sites and applications for competing companies might run each company’s Web services on the same server, but in different application pools. Using different application pools to isolate applications helps prevent one customer from accessing, changing, or using confidential information from another customer’s site.