IIS and Threads

Question

We are starting to write more and more code for an ASP.Net web application uses a new thread to complete long running tasks. I can find no solid documentation that give any useful guide to any limitations of restrictions of using threads within IIS (6). Any advice to this end would be appreciated - specifically the following:

• What (if any) is the max number of threads
• Is there a recommended max number
• Are there any pitfalls of using threads within an ASP.Net IIS web application?

Thanks for any advice

Answer 1

I assume you have already looked into Asynchronous ASP.NET page processing?

Answer 2

I myself have frequently done the same thing. What i found was that there is a maximum which is based on a "n number of threads per CPU" these can be adjusted and fine tuned in the web.config and machine.config files. This post has a reasonable explanation of this.

The recommended maximum would be the default setting, at least according to the documentation I have read from Microsoft on this topic sometime ago.

The biggest pitfall you will find you need to cross is how to report progress or the results back to the user. I typically use a polling mechanism from the client to call back to a page which checks the session state for progress. The session state is of course being updated from the main thread. If you want to see this approach working in real life see the House of Travel website and do a search for flights.

Answer 3

I can find no solid documentation that give any useful guide to any limitations of restrictions of using threads within IIS (6).

Mainly because this is a bad idea. Long running processes should be converted into windows services which either run continuously and occasionally check the database or whatever else for work to do or services that can be woken up by your asp.net app.

Answer 4

Improving .NET Application Performance and Scalability

http://msdn.microsoft.com/en-us/library/ms998530.aspx

10 Tips for Writing High-Performance Web Applications

http://msdn.microsoft.com/en-us/magazine/cc163854.aspx

Answer 5

Was going to make this a comment, but I realized it was more relevant than I thought. Eric Lippert has heard this set of questions before, and states that it is unanswerable.

So, in short, don't even go there. Come up with a design that uses a small number of threads and tune that.

Answer 6

Make sure that you only use threads when you're going to benefit. If your long-running code is CPU-intensive, then you won't actually benefit from making the call asynchronous (in fact, performance will decrease as there is an overhead).

Use threads for I/O operations or calling Web Services.

Each application is different. Simply setting the ThreadPool to max isn't the answer, or it would already be set at this level!

The higher you set the ThreadPool, the more you'll saturate the CPU, so IF you have CPU-intensive code then this will just compound the problem even more.

Of course, you could off-load these CPU-intensive calls onto another machine.

http://msdn.microsoft.com/en-gb/magazine/cc163327.aspx http://msdn.microsoft.com/en-us/magazine/cc163725.aspx