In IIS7 and ASP.NET, what is the exact relationship among:
IIS Worker Processes
Threads
AppDomains
Applications, and
incoming requests.
I'm hoping for an answer in a format similar to :
"Each IIS worker process hosts many appdomains which each spawn a single thread in response to each request...." etc. , and any nuances mentioned.
Each worker process hosts several AppDomains (at least one per ASP.NET app, i.e. a Website or Virtual Directory). An incoming request is assigned a thread from thread pool when it comes.
OP: Q. So each appdomain owns and manages its own thread pool?
Each managed Thread is always assigned to a single AppDomain at a time. The worker process maintains a shared thread pool and it's assigned to a specific AppDomain for the duration of a request.
Fritz Onion's book Essential ASP.NET has a chapter on HTTP Pipeline where he talks about relationship of all of the above during http request.
Related
Can anyone explain the differences, in IIS, between application pools, worker processes and app domains? Also, how do they work together? I've read a couple of articles but it's still a little confusing.
Does each website created in IIS becomes an application?
Is each application associated with one worker process?
Where do app domains come into the picture?
I try to say them with other words.
In a server you can have many asp.net sites that runs together. Each one site is an app domain.
You must assign to each of them one application pool. Many application domains (sites) can have the same application pool, and because they have the same application pool they run under the same processes, and under the same account - and they have the same settings of the pool. If this pool restarts, then all sites under that pools restarts.
Now each pool can have one or more worker process. Each worker process is a different program that's run your site, have their alone static variables, they different start stop calls etc. Different worker process are not communicate together, and the only way to exchange data is from common files or a common database. If you have more than one worker process and one of them make long time calculations, then the other can take care to handle the internet calls and show content.
When you assign many worker process to a single pool then you make the called web garden and your site is like to be run from more than one computer if a computer is one processing machine.
Each worker process can have many threads.
How the more worker process affect you:
When you have one worker process everything is more simple, among your application all static variables are the same, and you use the lock to synchronize them.
When you assign more than one worker process then you still continue to use the lock for static variables, static variables are not different among the many runs of your site, and if you have some common resource (e.g. the creation of a thumbnail on the disk) then you need to synchronize your worker process with Mutex.
One more note. Its sounds that when you make more worker process then you may have more smooth asynchronous page loads. There is a small issue with the session handler of asp.net that is lock the entire process for a page load - that is good and not good depend if you know it and handle it - or change it.
So let talk about one site only with many worker process. Here you face the issue that you need to synchronize your common resource change with Mutex. But the pages/handlers that use session they are not asynchronous because the session locks them. This is good for start because you avoid to make this synchronization of many points your self.
Some questions on this topic:
Web app blocked while processing another web app on sharing same session
jQuery Ajax calls to web service seem to be synchronous
ASP.NET Server does not process pages asynchronously
Replacing ASP.Net's session entirely
Now this session lock is not affect different sites.
Among different sites the more worked process can help to not the one site block the other with long running process.
Also among different sites the more pools also can help, because each pool have at least one worked process, but remember and see by your self using the process explorer, each working process takes more memory of your computer, and one big server with 16G memory and one SQL server can not have too many different worked process - for example on a server with 100 shared sites, you can not have 100 different pools.
One IIS server may have multiple application pools.
One web application binds to one application pool.
One application pool may have more than one worker process (when Web Garden is enable).
One worker process can have multiple app domains. One app domain lives only in one worker process.
One app domain may have multiple threads. One thread can be shared by different app domains in different time.
The meaning to ASP.NET developers: to make your web site scalable, don't use in-proc session and don't use static class variable lock for synchronization.
Yes, though not every application is a website. You can have an application that is nested under a website.
Yes, every application has to have one worker process (application pool), though one application pool can server several applications. A single web application can be distributed (web garden/farm) meaning that it will run in multiple processes.
Each process will run in its own app domain (every application pool is a separate app domain).
From MSDN.
Create a Web Application:
An application is a grouping of content at the root level of a Web site or a grouping of content in a separate folder under the Web site's root directory.
Application Pools:
An application pool defines a group of one or more worker processes, configured with common settings that serve requests to one or more applications that are assigned to that application pool. Because application pools allow a set of Web applications to share one or more similarly configured worker processes, they provide a convenient way to isolate a set of Web applications from other Web applications on the server computer. Process boundaries separate each worker process; therefore, application problems in one application pool do not affect Web sites or applications in other application pools. Application pools significantly increase both the reliability and manageability of your Web infrastructure.
From the source link:-http://weblogs.asp.net/owscott/archive/2007/09/02/application-vs-appdomain.aspx
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)
The worker process is used to process the request of the web application.
for IIS7
Does a webapplication run faster when Maximum Worker Processes is more than one?
By increasing the Maximum Worker Processes over 1 you're creating a Web Garden. So the short answer is: likely no... unless:
To quote Chris Adams an ex IIS PM's article I have flowers... should I get a Web Garden?:
Web gardens was designed for one single reason – Offering applications that are not CPU-bound but execute long running requests the ability to scale and not use up all threads available in the worker process.
The examples might be things like -
Applications that make long running database requests (e.g. high computational database transaction)
Applications that have threads occupied by long-running synchronous and network intensive transactions
The question that you must ask yourself -
What is the current CPU usage of the server?
What is the application’s threads executing and what type of requests are they?
Based on the criteria above, you should understand better when to use Web Gardens. Web Gardens, in the metabase, equals the MaxProcesses metabase property if you are not using the User Interface to configure this feature.
cscript adsutil.vbs set w3svc/apppools/defaultapppool/maxprocesses 4
I hope that I get some mileage out of having this blog and more importantly I hope it helps you understand this better…
You may want to look at "What is Web Garden?" from Deploying ASP.NET Websites on IIS 7.0 [codeproject.com] which says:
By default each Application Pool runs with a Single Worker Process (W3Wp.exe). We can assign multiple Worker Processes With a Single Application Pool. An Application Pool with multiple Worker process is called "Web Gardens". Many worker processes with the same Application Pool can sometimes provide better throughput performance and application response time. And each worker process should have their own Thread and Own Memory space.
WebGarden is faster than single worker process in case if application contains locks that prevent its parallelization. For example, GDI+ based image processing.
See this and this questions for more info.
I'm currently reading a lot about node.js. There is a frequent comparison between servers using a traditional thread per request model (Apache), and servers that use an event loop (Nginx, node, Tornado).
I would like to learn in detail about how a request is processed in ASP.NET - from the point it is received in http.sys all the way up to it being processed in ASP.NET itself. I've found the MSDN documentation on http.sys and IIS a little lacking, but perhaps my google-fu is weak today. So far, the best resource I have found is a post on Thomas Marquardt's Blog.
Could anyone shed more light on the topic, or point me to any other resources?
(For the purposes of this question I'm only interested in IIS7 with a typical integrated pipeline)
From my research so far, its my understanding that when a request comes in it gets put into a kernel-mode request queue. According to this, this avoids many of the problems with context switching when there are massive amounts of requests (or processes or threads...), providing similar benefits to evented IO.
Quoted from the article:
"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."
So according to that, every request queue may have more than one "Worker Process." (Google cache) More on worker processes
From my understanding:
IIS Opens creates a request queue
(see the http.sys api below)
A "Web Site" configured in IIS corresponds to one Worker Process
A Web Site/Worker Process shares the Thread Pool.
A thread is handed a request from the request queue.
Here is a lot of great information about IIS7's architecture
Here is some more information about http.sys.
HTTP Server I/O Completion Stuff
Typical Server Tasks
Open questions i still have:
How the heck does IIS change the Server header if it Uses HTTP.SYS? (See this question)
Note: I am not sure if/how a "Kernel-mode request queue" corresponds to an IO completion port, I would assume that each request would have its own but I don't know, so I truly hope someone will answer this more thoroughly. I just stumbled on this question and it seems that http.sys does in fact use IO Completion ports, which should provide nearly all of the same benifits that evented IO (node.js, nginx, lighttpd, C10K, etc...) have.
I'm investigating some performance improvements that can be made to our web server and ASP.NET application. This page contains a few things that we can do.
We currently have two worker processes running as a garden. Do each of these worker processes have their own ASP.NET threadpool? Or do both of these worker processes share a single threadpool and the max number of worker threads is shared across these processes?
This post seems to suggest that the two processes share a common ASP.NET threadpool.
All w3wp.exe threads do is take
requests from HTTP.SYS queue, process
it, and hand the request to
ASPNET_ISAPI.DLL, who then deposits
those requests into the ASP.Net
request queue, and the ASP.Net threads
service that queue.
But this post suggests that each worker process contains their own ASP.NET threadpool.
Each process (w3wp.exe) has its own
CLR thread pool which has the
configured maxworkerthreads value (20
default).
Which is correct?
Each worker process will have its own thread pool and separate ASP.NET request queue.
Processes can't really share threads, threads run in the context of a single process.
as i understand, when i load a asp.net .aspx page on the (iis)server, it's processed via the w3p.exe process.
But when iis gets multiple requests, are they all processed by the same w3p process?
And does this process automaticly use all my processors and cores?
And after that: when i start i new thread in my page, this thread still works when the pages is already served to the client.
Where does this thread live? also in the w3p.exe process?
And what if i assign another apppool to my site, what does that do?
Michel
IIS creates a separate worker process (w3wp.exe on Windows Server or aspnet_wp.exe on Windows XP) for each App Pool. If you create multiple App Pools it will create multiple worker processes. When a page gets multiple requests, yes, they are processed by multiple threads in the same worker process. Each thread can run on a separate processor or core, so yes. When you start a new thread manually it's no different - yes, it's in the same worker process.