I noticed today that the maximum threadpool count in ASP.NET 2.0 is set to 100 worker and 100 I/O threads per cpu, and from what I can tell, these values are not easily modifiable. [Update: it actually is easily modifiable, just as it was in 1.1, using the processModel element in machine.config.] (You can check the threadpool maxima by calling ThreadPool.GetMaxThreads in any process). This is in contrast with 1.1 where the default was 20 worker and 20 I/O threads per cpu, which could be adjusted with the processModel element in machine.config.
This seems like a good decision overall to me. The threadpool will likely never max out at 100 even under heavy load because of the heuristics for thread allocation built into the threadpool. During some load testing, I couldn't even get the threadpool to allocate more than 30 threads with two client machines pummeling a server full bore. In 1.1 it was actually pretty easy to hit the 20 thread limit with any load, and if your requests were I/O-bound it actually became the limiting factor in the requests your server could handle.
Rather than tweaking the threadpool limits, however, developers should be focused on using the threads that are allocated to their requests efficiently, like using async I/O when possible, and tapping into the new async tasks and async page features of ASP.NET 2.0 when it makes sense.
Interestingly, if you check the threadpool maxima in a console or Winforms app, they are set to 25 worker threads and 1000 I/O threads (yes that's 1.0x10^3). It seems somewhat odd that the ASP.NET runtime changes the 1000 upper bound for I/O threads, which is obviously meant to mean 'unbounded' for all intents and purposes. I wonder if dropping it to 100 was intended as a real constraint (one you'd be unlikely to run into, although certainly more likely than 1000) or just a case of maintaining symmetry...
 |
Limited training time? Need to learn ASP.NET 2.0 and SQL Server 2005?
|
Posted
Apr 11 2006, 01:23 PM
by
fritz-onion