Asynchronous Programming in ASP.NET

[senfo]

I recently read an MSDN article by Jeff Prosise titled, Scalable Apps
with Asynchronous Programming in ASP.NET
(http://msdn.microsoft.com/msdnmag/issues/07/03/WickedCode/).

In the article, Jeff discusses scaling problems that some users
experience with ASP.NET applications. The problem, Jeff writes, isn't
that ASP.NET isn't capable of scaling; but has more to do with ASP.NET
applications that use threads inefficiently. In the article, Jeff
writes, "One solution is to increase the maximum size of the thread
pool, allowing more threads to be created." He later goes on to say,
"But increasing the thread count-or the server count-doesn't solve the
issue. It just provides temporary relief to what is in reality a design
problem-not in ASP.NET itself, but in the implementation of the actual
site."

This has become the topic of debate among other developers I know who do
not see issues with raising the number of threads in the thread pool.

What would happen if, for example, somebody were to raise the number of
available threads in the pool to something like 100 threads? What about
1,000? That should provide more than ample breathing room, but does it
have an adverse affect (besides, as Jeff writes, that it only provides
temporary relief)?

Could anybody please expand on that?

Thank you in advance,

 

[John Timney \(MVP\)]

Every thread that gets executed consumes resources. If you increase a
thread pool on a busys site which is maxing out at 100 threads to 1000
threads you need 10 times more processing power, 10 times more ram -
possibly ten times more worker processes per application depending on what
your app is actually doing and what each asynchronous request is actually
trying to complete. Each thread competes for resources, so you can end up
deadlocking your application. Jeff is likely implying that you cant simply
scale by adding threads and thats the end of it, you have to design scale in
and that may involve adding threads by adding physical servers into a load
balanced farm instead of overloading existing servers.
--
Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[John Saunders]

I recently read an MSDN article by Jeff Prosise titled, Scalable Apps with
Asynchronous Programming in ASP.NET
(http://msdn.microsoft.com/msdnmag/issues/07/03/WickedCode/).

In the article, Jeff discusses scaling problems that some users experience
with ASP.NET applications. The problem, Jeff writes, isn't that ASP.NET
isn't capable of scaling; but has more to do with ASP.NET applications
that use threads inefficiently. In the article, Jeff writes, "One
solution is to increase the maximum size of the thread pool, allowing more
threads to be created." He later goes on to say, "But increasing the
thread count-or the server count-doesn't solve the issue. It just provides
temporary relief to what is in reality a design problem-not in ASP.NET
itself, but in the implementation of the actual site."

This has become the topic of debate among other developers I know who do
not see issues with raising the number of threads in the thread pool.

What would happen if, for example, somebody were to raise the number of
available threads in the pool to something like 100 threads? What about
1,000? That should provide more than ample breathing room, but does it
have an adverse affect (besides, as Jeff writes, that it only provides
temporary relief)?

Could anybody please expand on that?

To my mind, Jeff Prosise is correct here. You should first solve the
underlying problem, which is not correctly implementing asynchronous
programming in ASP.NET. Then, if you have to, increase the size of the
thread pool.

Otherwise, you're solving the wrong problem. Like adding hardware because
your software doesn't perform well.

John

 

[Guest]

In addition to what has been already recommended, one should know that the
ASP.NET framework with IIS is already optimized for maximum scalability, and
under normal conditions there is no need to monkey around with threadpool
settings. There are certain "tweaks" that you can find by reading the
whitepapers, but usually a lack of scale in an app is more due to developer
stupidity or not understanding what async pages and programming "buys you".

If you have operations in a page that can gain scale through
parallelization, async may help. Otherwise, you are ultimately still waiting
for everything until page processing can complete, which buys nothing.
Peter