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?
