Asynchronous Programming in ASP.NET

Discussion in 'ASP .Net' started by senfo, Apr 10, 2007.

  1. senfo

    senfo Guest

    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,

    --
    Sean

    website: http://senfo.blogspot.com
     
    senfo, Apr 10, 2007
    #1
    1. Advertising

  2. 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


    "senfo" <-WANT-NO-SPAM> wrote in message
    news:...
    >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,
    >
    > --
    > Sean
    >
    > website: http://senfo.blogspot.com
     
    John Timney \(MVP\), Apr 10, 2007
    #2
    1. Advertising

  3. "senfo" <-WANT-NO-SPAM> wrote in message
    news:...
    >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
     
    John Saunders, Apr 10, 2007
    #3
  4. 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

    --
    Site: http://www.eggheadcafe.com
    UnBlog: http://petesbloggerama.blogspot.com
    Short urls & more: http://ittyurl.net




    "senfo" wrote:

    > 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,
    >
    > --
    > Sean
    >
    > website: http://senfo.blogspot.com
    >
     
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=, Apr 10, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anders Both
    Replies:
    3
    Views:
    507
    Kevin Spencer
    Jan 5, 2004
  2. =?Utf-8?B?U3JpcmFtIE1hbGxhanlvc3VsYQ==?=

    Asynchronous programming in ASP.Net 2.0

    =?Utf-8?B?U3JpcmFtIE1hbGxhanlvc3VsYQ==?=, May 2, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    368
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    May 2, 2007
  3. Tvrtko
    Replies:
    2
    Views:
    222
    Tvrtko
    Sep 24, 2009
  4. Pierre
    Replies:
    0
    Views:
    353
    Pierre
    May 17, 2010
  5. Ravil Bayramgalin

    Easy asynchronous programming

    Ravil Bayramgalin, Nov 6, 2010, in forum: Ruby
    Replies:
    1
    Views:
    97
    Tony Arcieri
    Nov 7, 2010
Loading...

Share This Page