Threadpool in IIS context

views:

553

answers:

+1 Q:

Threadpool in IIS context

Hi.

I have a general question about System.Threading.Threadpool when run in a webapplication on IIS. Say we have 2 requests execute at once, and we fire up a couple of threads through the ThreadPool.QueueUserWorkItem method. Will the two requests share the ThreadPool, or will the calls to the ThreadPool from the two requests operate in a two separate pools?

This is in IIS6 and 7.

Thanks for any insight.

+3 A:

Here is a quote from the MSDN documentation about the ThreadPool class:

There is one thread pool per process. The thread pool has a default size of 250 worker threads per available processor, and 1000 I/O completion threads.

In II6 and II7 any given ASP.NET application is hosted inside of a single process (w3wp.exe) through the Application Pool infrastructure.
An Application Pool can host multiple web applications by keeping them in different AppDomains, but it runs inside of one physical process on the server.

These two facts mean in practice that all threads from a running web application instance execute inside the same .NET Thread Pool.

Enrico Campidoglio 2009-09-21 08:56:41

So this basically means that using ThreadPool for web applications that need to fire tasks into several threads is a bad idea.

El Che 2009-09-21 10:29:57

Since all web requests are already handled asynchronously, I would say that in most cases you don't gain any significant benefit from running operations in background threads in web applications. An exception would probably be if you don't wish to block the processing of a request to wait on a long-running operation. In this case you could fire a background thread, do some more work on the request, and then finally wait for it to complete before you send the response to the client.

Enrico Campidoglio 2009-09-21 10:52:49

In my case, I have a service that runs in an IIS context, and that does X number of outgoing requests to different searchengines. These should be done in several threads since I want to maximize speed here. When all threads are complete, I collect the results into one resultlist and return it to the caller.The reason for using a pool in this case is just to use less memory, since it reuses the threads in the pool. But if I use the same pool as IIS uses, then this might not be a good class to use.

El Che 2009-09-21 11:03:23

Well, in your case it makes perfect sense to use background threads, since you want to execute multiple operations in parallel. In general, it is a good idea to use the Thread Pool instead of manually creating threads manually, for exactly the reasons you mentioned. If your site isn't handling a huge amount of traffic, the Thread Pool can probably satisfy all the requests without starving. However it is a good idea to have your web application running in its own Application Pool, to make sure it doesn't have to share the Thread Pool with others.

Enrico Campidoglio 2009-09-21 11:58:50

Thanks for a very relevant and good discussion, Enrico. Very helpful

El Che 2009-09-21 12:21:52

The pleasure is all mine :-)

Enrico Campidoglio 2009-09-21 14:43:51

ansaurus

tags:

views:

answers:

Threadpool in IIS context

related questions