I'm curious to the cost of a thread. The reason is that we're trying to determine whether we should look at making use of async pages and async WCF (hosted under IIS/ASP.NET). To me the answer seems simple, of course we should move to async. Why have a thread tied up waiting for IO when you can return it to the pool and service another request. However others have said that so far we don't see any queueing and the processor utilization is very low.
I believe we're running on 16 CPU boxes now and are moving to 24 CPU boxes soon. Currently we're still running under a 32 bit OS, Windows 2003 I think. I believe most web applications are targeting .NET 2.0 to 3.5. The current worker threads setting is somewhere around 100 which would mean on a 24 CPU box we could get up to 2,400 threads.
Most web application requests will incur some IO, either making one or more calls to a database or will make a web service call to an internal service. It's likely then that the time consumed by IO will be greater than the CPU time executing the page. It seems obvious then that moving to async would make better use of the resources on the box allowing you to process the same number of requests with fewer threads. However there's a cost to moving to async as the server side code would have to change
View Complete Post