How are IIS7 threads assigned?

I added log4net to my application and can now see the thread Ids of user activities as they navigate through my website. Is there any specific algorithm to how threads assignment happens with IIS7, or is it just a random number assignment (I suspect it's not completely random because开发者_如何学运维 my low traffic site show threads mostly in the range 10-30)? Any maximum to the number of threads available? And I notice that my scheduler shows up with a weird threads id -- any reason for this? The scheduler is Quartz.net and the id shows as "Scheduler_Worker-10", and not just a number.

This explains all you need to know.

An Excerpt:

When ASP.NET is hosted on IIS 7.0 in integrated mode, the use of threads is a bit different. First of all, the application-level queues are no more. Their performance was always really bad, there was no hope in fixing this, and so we got rid of them. But perhaps the biggest difference is that in IIS 6.0, or ISAPI mode, ASP.NET restricts the number of threads concurrently executing requests, but in IIS 7.0 integrated mode, ASP.NET restricts the number of concurrently executing requests. The difference only matters when the requests are asynchronous (the request either has an asynchronous handler or a module in the pipeline completes asynchronously). Obviously if the reqeusts are synchronous, then the number of concurrently executing requests is the same as the number of threads concurrently executing requests, but if the requests are asynchronous then these two numbers can be quite different as you could have far more reqeusts than threads.

So basically, if requests are synchronous, the same number of threads per request. See here for various parameters.

I've explained this is a blog post on my blog ASP.NET Performance-Instantiating Business Layers

The title doesn't coincide with your question but I explain the way IIS handles Requests and I believe you'll have your answer.

A quote from the article

When IIS fields a request for your application it hands it over to the worker process. The worker process in turn creates and instance of your Global class (which is of type HttpApplication). From that point on the typical flow of an ASP.NET application takes place (the ASP.NET pipeline). However, what you need to know and understand is that the worker process (think of it as IIS really) keeps the instance of your HttpApplication (an instance of your Global class) alive, in order to field other requests. In fact it by default it would create and cache up to 10 instances of your Global class, if required (Lazy instantiation) depending on load the number of requests your website receives other factors. In Figure1 above the instances of your ASP.NET application are shown as the red boxes. There could be up to 10 of these cached by the worker process. These are really threads that the worker process has created and cached and each thread has its own instance of your Global class. Note that each of these threads is in the same App Domain. So any static classes you may have in your application are shared across each of these threads or application instances.

I suggest you read that article and I'll be happy to answer any questions you may have. Please note that I've intentional kept the article simple in that I don't talk about what happens in the kernel or go into details of the various components that participate. Keeping it simple helps people understand the concepts a lot better (I feel).

I'll answer some of your other questions here:

1. Is there any specific algorithm to how threads assignment happens with IIS7?

No, for all intents an purposes it's random. This is explain in the article I pointed to. The short answer is that if a cached thread is available then IIs will use it. If not, it will create a new thread, create and instance of your HttpApplication (Global) and assign all of the context to it. So in a site that's not busy, you may see the same threads handle requests. But there are no guarantees. If there is more than one free thread IIS will pick a thread at random to service that request. You should note here, that even in a not so busy site, if your requests take a long time, IIS will be forced to create new threads to service other incoming requests.

1. Any maximum to the number of threads available?

Yes (as explained in th article) typically 10 threads per worker process. This can be adjusted but I've worked on a number of extremely busy websites and I've never had to. The key is to make your applications respond as fast as possible. Mind you an application can have multiple worker process assigned to it (configured in your app pool) so in busy sites you actually want multiple worker processes for your application, however the implication is that you have the required hardware (CPU cores and memory).

1. The scheduler is Quartz.net and the id shows as "Scheduler_Worker-10", and not just a number

Threads can have names instead of Ids. If the thread has been assigned a name then you'll see that instead of an id. Of course for threads IIS creates you have no such control. Mind you, I've not used (nor know about Quartz) so I don't know about that but I'm guess that's the case.