![]() |
validity of a statement from a book
"Asynchronous Web pages can improve performance in scenarios where the thread pool might be limiting performance." The asynchronous stuff is done using IHttpAsyncHandler. Wouldnt it use the same threads from the thread pool? |
Re: validity of a statement from a book
yes and no.
whether your page can benefit from being written as asynchronous depends on how many i/o, network or database calls the page makes. a typical database call may take 50-100ms. during this time, the request thread is tied up in an i/o wait. if the asynchronous model is used, during this wait, the thread could be used to process another request that is not in an i/o state. the trick to understand is that the page processing event model allows switching the request processing thread at each page event (this was true in asp.net 1.0). asynchronous i/o was dangerous in this model, as the completion notification of the asynchronous event happens on the thread that started it. this was a problem if asp switched the processing thread during the request before completion of the asynchronous request. with the new model, there is an page cycle event where all asynchronous requests are started, and a page cycle event that called when all the requests have completed. due to thread switching during a request this is still the only supported way to use asynchronous requests. this is also why thread local storage will not work, or any thread context changes made during processing of a page request. -- bruce (sqlwork.com) parez wrote: > "Asynchronous Web pages can improve performance in scenarios where the > thread pool might be limiting performance." > > The asynchronous stuff is done using IHttpAsyncHandler. Wouldnt it use > the same threads from the thread pool? |
| All times are GMT. The time now is 03:22 PM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.