Worker Process, Work threads, Application Pool, AppDomain, Web Site,
Worker Process
=============
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.
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.
The w3wp.exe worker process 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.
Application Pool
=============
An Application Pool can contain one or more applications and allows us to configure a level of isolation between different Web applications
Web Application VS Worker Process
=============
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.
Aach application pool runs in its own worker process, errors in one application pool will not affect the applications running in other application pools.
AppDomain
=============
AppDomain can be considered as a Lightweight process which is both a container and boundary.
The .NET runtime uses an AppDomain as a container for code and data, just like the operating system uses a process as a container for code and data.
As the operating system uses a process to isolate misbehaving code, the .NET runtime uses an AppDomain to isolate code inside of a secure boundary.
The CLR isolates each application domain from all other application domains and prevents the configuration, security, or stability of a running .NET applications
from affecting other applications.
An AppDomain can be destroyed without effecting the other Appdomains in the process.
Mulitple Appdomains can exist in Win32 process.
Win32 processes provide isolation by having distinct memory addresses. The .Net runtime enforces AppDomain isolation by keeping control over the use of memory. All memory in the App domain is managed by the run time so the runtime can ensure that AppDomains Do not access each others memory.
ApplicationPool VS AppDomain
==============
Appdomain is a container within which ASPX runs.
AppPool is a process that starts the w3wp.exe worker process within which ASP applications run.
Threading in ASP.NET Pipeline
==============
ASP.NET creates a distinct AppDomain for each application housed in its worker process, but what has not yet been mentioned is how threads are allocated and dispatched to service those requests.
To begin with, ASP.NET uses the process-wide CLR thread pool to service requests. The size of this pool is configurable in the processModel element of machine.config, and is set to a default of 25 worker threads and 25 I/O threads.
In IIS 6.0, there is no dedicated worker process for ASP.NET since it is integrated into the process model exposed by IIS 6.0, which lets you designate whether a particular virtual directory lives in a distinct worker process (w3wp.exe) or in a worker process shared by other virtual directories. In this scenario, ASP.NET services requests on worker threads drawn from the process-wide CLR thread pool.
For each request that comes in, a new instance of the appropriate HttpApplication-derived class is created, as are the associated modules for that application. To avoid reallocating applications and modules too often, each AppDomain maintains a pool of applications and modules. The maximum size of the application pool is the same as the size of the thread pool, so by default, up to 25 requests per worker process can be processed concurrently, each with its own application and module set.
Below is a possible snapshot in time of the ASP.NET worker process. In this scenario, there are two active applications in the worker process, each with a dedicated AppDomain. Each application is currently processing two requests, and each is using two threads from the ASP.NET thread pool to service those requests.
Applys for IIS5
Over All
==============
-
An application is an IIS term, but it's one that ASP.NET utilizes. Essentially it creates a sandbox, or a set of boundaries to separate different sites, or parts of sites, from the others.
-
An AppDomain is a .NET term. (In IIS7, AppDomains play a larger role within IIS, but for the most part it's an ASP.NET term)
-
An AppDomain contains InProc session state (the default session state mode). So if an AppDomain is killed/recycled, all of your session state information will be lost. (if you are using the default InProc session state)
- Applications can have multiple AppDomains in them although often times there is a one-to-one relationship between them.
-
In IIS6 and greater, there is the option of creating groups, or "pools" of applications that can be bundled together or separated; however the server administer decides. These are called Application Pools. Each app pool runs under its own w3wp.exe worker process.
-
In IIS, it's easy to see an application. A new website is a separate application and any subfolder can be marked as an application. When they are, the icon beside the folder turnes into a picture of some gears. By right-clicking on the folder, you have the option of marking a folder as an application or removing it as an application, if it already is one. Also, in IIS6, in the Application Pools section, you can see all of the applications and which app pool they live under.
-
ASP.NET, on the other hand, doesn't give much visibility into AppDomains, at least not from any visual tools. This is done behind the scenes. Programmatically you can create them, tear them down or see a list of all running AppDomains.
-
You can recycle an application from IIS. In IIS5, you can't do it directly unless you recycle the entire web server, but in IIS6 and greater, you can recycle the application pool that the application lives under. It will gracefully die off and a new application will start up to replace it. Or, to word it another way, another w3wp.exe worker process will be started and then the old one will die off after it completes any currently running page requests.
-
You can recycle an AppDomain in ASP.NET through the 'touch trick'. There are a few ways to do it, but the most straight forward is to edit your web.config file in notepad and add a space to an insignificant place. Then save the file. This will cause the AppDomain to recycle. This *does not* touch the IIS application though.
-
Recycling an AppDomain will come pretty close to starting ASP.NET fresh again for that particular ASP.NET application, so although it doesn't recycle the apppool, it can give ASP.NET a fresh start in many situations.
Worker Processes (IIS 6.0)
ASP.NET Internals – IIS and the Process Model
http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel.aspx
AppDomain concept in ASP.Net
http://www.c-sharpcorner.com/UploadFile/nagryum/Appdomain07102007081415AM/Appdomain.aspx
Application vs. AppDomain
http://weblogs.asp.net/owscott/archive/2007/09/02/application-vs-appdomain.aspx
