This topic is quite interesting and I have been through many articles and books, below set of information are much useful for complete understanding on the request handling mechanism.
Step I: When a request comes in:
- IIS creates/runs the work processor (w3wp.exe) if it is not running.
- The aspnet_isapi.dll is hosted in the w3wp.exe process. IIS checks for the script map and routes the request toaspnet_isapi.dll.
- The request is passed to the .NET runtime that is hosted into w3wp.exe as well.
Step II: Below, you can see all the steps the request has to pass though before it is elaborated.
Application Manager :
The first object we have to talk about is the Application Manager.
Application Manager is actually an object that sits on top of all running ASP.NET AppDomains, and can do things like shut them all down or check for idle status.
For example, when you change the configuration file of your web application, the Application Manager is in charge to restart the AppDomain to allow all the running application instances (your web site instance) to be created again for loading the new configuration file you may have changed.
Requests that are already in the pipeline processing will continue to run through the existing pipeline, while any new request coming in gets routed to the new AppDomain. To avoid the problem of “hung requests”, ASP.NET forcefully shuts down the AppDomain after the request timeout period is up, even if requests are still pending.
Application Manager is the “manager”, but the Hosting Environment contains all the “logic” to manage the application instances. It’s like when you have a class that uses an interface: within the class methods, you just call the interface method. In this case, the methods are called within the Application Manager, but are executed in the Hosting Environment (let’s suppose the Hosting Environment is the class that implements the interface).
At this point, you should have a question: how is it possible the Application Manager can communicate with the Hosting Environment since it lives in an AppDomain? (We said the AppDomain creates a kind of boundary around the application to isolate the application itself.) In fact, the Hosting Environment has to inherit from theMarshalByRefObject class to use Remoting to communicate with the Application Manager. The Application Manager creates a remote object (the Hosting Environment) and calls methods on it
So we can say the Hosting Environment is the “remote interface” that is used by the Application Manager, but the code is “executed” within the Hosting Environment object.
On the previous paragraph, I used the term “Application” a lot. HttpApplication is an instance of your web application. It’s the object in charge to “elaborate” the request and return the response that has to be sent back to the client. An HttpApplication can elaborate only one request at a time. However, to maximize performance,HttpApplication instances might be reused for multiple requests, but it always executes one request at a time.
This simplifies application event handling because you do not need to lock non-static members in the application class when you access them. This also allows you to store request-specific data in non-static members of the application class. For example, you can define a property in the Global.asax file and assign it a request-specific value.
You can’t manually create an instance of HttpApplication; it is the Application Manager that is in charge to do that. You can only configure what is the maximum number of HttpApplications you want to be created by the Application Manager. There are a bunch of keys in the machine config that can affect the Application Manager behavior:
Hide Shrink Copy Code
With maxWorkerThreads and minWorkerThreads, you set up the minimum and maximum number ofHttpApplications.
For more information, have a look at: ProcessModel Element.
Just to clarify what we have said until now, we can say that against a request to a WebApplication, we have:
- A Worker Process w3wp.exe is started (if it is not running).
- An instance of ApplicationManager is created.
- An ApplicationPool is created.
- An instance of a Hosting Environment is created.
- A pool of HttpAplication instances is created (defined with the machine.config).
Until now, we talked about just one WebApplication, let’s say WebSite1, under IIS. What happens if we create another application under IIS for WebSite2?
- We will have the same process explained above.
- WebSite2 will be executed within the existing Worker Process w3wp.exe (where WebSite1 is running).
- The same Application Manager instance will manage WebSite2 as well. There is always an instance per Work Proces w3wp.exe.
- WebSite2 will have its own AppDomain and Hosting Environment.
- Within a new AppDomain will be run instances of WebSite2 (HttpApplication instances).
It’s very important to notice that each web application runs in a separate AppDomain so that if one fails or does something wrong, it won’t affect the other web apps that can carry on their work. At this point, we should have another question:
What would happen if a Web Application, let’s say WebSite1, does something wrong affecting the Worker Process (even if it’s quite difficult)?
What if I want to recycle the application domain?
To summarize what we have said, an AppPool consists of one or more processes. Each web application that you are running consists of (usually, IIRC) an Application Domain. The issue is when you assign multiple web applications to the same AppPool, while they are separated by the Application Domain boundary, they are still in the same process (w3wp.exe). This can be less reliable/secure than using a separate AppPool for each web application. On the other hand, it can improve performance by reducing the overhead of multiple processes.
An Internet Information Services (IIS) application pool is a grouping of URLs that is routed to one or more worker processes. Because application pools define a set of web applications that share one or more worker processes, they provide a convenient way to administer a set of web sites and applications and their corresponding worker processes. Process boundaries separate each worker process; therefore, a web site or application in an application pool will not be affected by application problems in other application pools. Application pools significantly increase both the reliability and manageability of a web infrastructure.