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.
Related
How to know how many threads created by IIS for each worker process.
If my concurrent users are 100 and each user may send 30-40 API calls through the web page. Is IIS default settings are sufficient to handle with the load without any wait/queue time or DO I need to increase the Threads Per Processor Limit.
I have 8 core process machine on which my web app is deployed.
I'm working on a legacy application where an ASP.NET HttpHandler is running its own threadpool which loads its own instances of out of process COM objects. Requests come in and pass a workload to these COM objects and when complete return the results.
The processing works fine and you definitely see the pool is working as simultaneous requests come in are processed reliably... as long as the pool thread count stays under 10 and the pool is not saturated with busy request. Once the pool saturates neither COM requests, nor plain ASP.NET Handler requests hit the ASP.NET pipeline any more, until the pool frees up an instance.
When I run the threadpool with 16 instances and hit the server with long running (waiting) requests that take 5 seconds to complete, I can see exactly 10 instances get loaded up with work. Any instances beyond that are never hit. Not only that - even straight handler requests that don't hit the COM pool also start queuing at this point.
More info:
COM Pool is created with MTA Threads (but STA doesn't change anything)
COM objects are STA threaded and out of process EXEs
COM objects execute on the same fixed thread they were created on (ie. there's no COM thread marshalling)
ASP.NET thread signals the Pool thread to start processing
Currently the ASP.NET Context gets passed to the pool thread
Running .NET 4.5
Testing on Windows 10 Pro
The reason I use a custom thread pool is because of the COM dependency and the need to ensure the COM objects stay loaded on the same thread without COM marshalling. As mentioned it works fine until the point were all instances are busy and only then does everything stop until the pool frees up a new instance.
I can understand that the COM objects might be blocked, but I really don't get why the main ASP.NET thread would fail to process even a raw handler request (ie. I have a flag that runs a plain Response.Write() response and returns and it sits and waits just like the COM requests when the pool is saturated)
I suspect it has to do with the COM object instantiation, but I'm baffled why this would occur when the objects are created on non-ASP managed threads.
Has anybody seen behavior like this where ASP.NET simply will not create new request threads and simply queue?
IIS on a client OS (e.g. Windows 7) has limits on the number of concurrent connections. For instance, see http://forums.iis.net/p/1229666/2114928.aspx?Is+there+an+Concurrent+Request+Limit+on+IIS+8+5+.
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.
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.
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.