Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?
roberto3214_at_netscape.net
Date: 01/21/05
- Next message: Sameer: "DNS entries and shared codebase"
- Previous message: Pat [MSFT]: "Re: IIS crash"
- In reply to: David Wang [Msft]: "Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?"
- Next in thread: David Wang [Msft]: "Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?"
- Reply: David Wang [Msft]: "Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?"
- Messages sorted by: [ date ] [ thread ]
Date: 21 Jan 2005 14:13:35 -0800
Thanks David,
I think I grasp the concept between the two scenarios sync and async.
One thing I'm still unclear about is what happens if your main thread
has no other work to do then you are forced to wait for the async
result or else your page will complete without the desired result. Here
is an example of what I mean:
IO Thread starts executing the Web Page
Web Page makes HTTP request (async) to web service say in the case a
temperature webservice
Webpage then does some processing on the result I get from the
webservice, say convert temp from fahrenheit to celcius.
Web Page displays the content of the HTTP response
Web Page finishes, returns "success", and releases IO thread to do
other work
Now with this example when I send the request to temperature webservice
(async), my main IO thread can't do anything else unless it gets the
return value of the webservice since so in this case I would have to
wait for the request to finish is this correct? Also say I didn't wait
for the result in my main page then what will happen is the request
will be fired off to webservice the page will return back to the client
with incorrect result since we haven't got the result from webservice,
then at some point the request from webservice will come back but it
will be too late because the response has already been displayed to the
client. Is my thinking incorrect here?
The way I understand async programming is if u need to do other kinds
of long process work that aren't needed straight away to continue
processing the job. Say if u had to log something to the database. But
in the above example its clear that if you fire a request to webservice
nothing more can be done until the result is back.
> point of asynchronous programming on the web is to schedule some work
item
> to be done LATER and immediately freeing up the original thread.
That
> queued up work item can take its time, use other non-IO threads to do
work,
> and eventually return a response.
I agree with the above point
> In asynchronous, the IO thread
> queue's up the HTTP request and immediately returns back and can
handle
> other incoming requests (i.e. low latency). Whenever the callback
happens
> to occur, the request processing completes on some other thread
designed to
> be used to send the response.
In regards to this point does this mean for my temperature example
above that once I have fired an async request to the webservice my IO
thread isn't tied anymore as long as I don't wait for the result? If so
wouldn't the page just end and then eventually the result will come
back but the user may never see it?
Sorry for asking so many questions just want to get really clear on
this, as it looks like its a key concept to effective programming on
the web
Thanks for your time and effort
Regards Rob
David Wang [Msft] wrote:
> There are documents on MSDN describing the formula used to calculate
ASP.Net
> threads in relation to CPU. I can't remember the link at the moment.
>
> Re: question about asnyc call
>
> If you poll for the async return, then that is not really
asynchronous.
> Remember, you can always fake a synchronous operation by making an
> asynchronous operation and then waiting for its completion function.
The
> point of asynchronous programming on the web is to schedule some work
item
> to be done LATER and immediately freeing up the original thread.
That
> queued up work item can take its time, use other non-IO threads to do
work,
> and eventually return a response. If you wait for the work item on
the
> original thread, then it really wasn't asynchronous.
>
>
> Given your example of a web page making a web service call to
retrieve data
> and display it, here is what synchronous and asynchronous versions
would
> look like:
>
> Synchronous:
> IO Thread starts executing the Web Page
> Web Page makes HTTP request (sync or async) to web service
> Web Page waits for HTTP response to return (either with a callback or
not)
> Web Page displays the content of the HTTP response
> Web Page finishes, returns "success", and releases IO thread to do
other
> work
>
> Asynchronous:
> IO Thread starts executing the Web Page
> Web Page makes async HTTP request to web service and informs it to
invoke a
> delegate as callback
> Web Page immediately returns "pending" and releases IO thread to do
other
> work (response is sent on completion callback...)
>
> At some point, HTTP request completes and triggers asnyc completion
of your
> callback delegate
> Some thread invokes your delegate callback function
> Callback function displays the content of the HTTP response
> Callback function finishes, returns "success", and releases this
thread
>
> I realize that asynchronous operation is quite subtle as a concept
and takes
> some time getting used to it.
>
> The key thing to note is that in synchronous, the IO thread is
waiting for
> the HTTP response to return and hence cannot handle any other
incoming
> requests (i.e. your web page is latent). In asynchronous, the IO
thread
> queue's up the HTTP request and immediately returns back and can
handle
> other incoming requests (i.e. low latency). Whenever the callback
happens
> to occur, the request processing completes on some other thread
designed to
> be used to send the response.
>
> Since ASP.Net depends on the worker threads to "do work", if you have
high
> latency operations tying up the worker threads, it directly affects
> ASP.Net's ability to handle incoming request load. The two ways to
combat
> this situation are to either decrease request latency by using
asynchronous
> operations, or increase number of worker threads at the cost of
increased
> concurrency costs (like context switching). The best solution is to
decrease
> latency but can be hard to implement; the easy solution is to just
bump
> worker thread count up. Just realize that the easy solution has
limits and
> impacts the system in other ways.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> <roberto3214@netscape.net> wrote in message
> news:1106231032.332459.122470@f14g2000cwb.googlegroups.com...
> Hi David,
>
> Thanks for your comments I have since done further tests before
reading
> your post mainly with increasing the number of worker processors web
> garden setting in iis 6.0 there seems to be a direct relationship
> between increasing this number and number of requests per second
> increase. As you have stated response times for pages may degrade.
>
> But I do have a couple of followup questsions. In the above example
of
> 1 sec delay starving the asp.net of its worker process, I understand
> that an async call to do such a task will not hog up the worker
process
> but wouldn't u still have to poll or wait for the result to come
back?
> Say you wanted to get the current temperature using a webservice and
it
> took say 1 second to get a response even though I use an async method
> woulnd't i have to poll on my webpage to get a result back? And if so
> does that mean I'lll be starving the asp.net of worker process?
>
> Secondly you mentioned there is a relationship between CPU and
ASP.Net
> IO worker threads, what is the relationship? IF I have 1 cpu on
average
> how many asp,net io worker threads do I have?
> Thanks for your time and effort
> Regards DotnetShadow
- Next message: Sameer: "DNS entries and shared codebase"
- Previous message: Pat [MSFT]: "Re: IIS crash"
- In reply to: David Wang [Msft]: "Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?"
- Next in thread: David Wang [Msft]: "Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?"
- Reply: David Wang [Msft]: "Re: W2K3 IIS 6.0 ASP.NET Requests Per Second Limits?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|