0

Imagine we have an aspx web page that calls a stored procedure and 15 minutes later renders a table of data on a GridView. In my hypothetical, I'm not running, say, 4 asych which could happen in parallel-- just one long database proc.

At at least 3 places on the call stack, Microsoft lets me attempt to do things the asynch way, with async pages and web methods, async ADO.NET calls and things like the async key word and asynchronous delegates.

eg:

[WebMethod]
public IAsyncResult BeginLengthyProcedure( AsyncCallback cb, object s) {...}
[WebMethod]
public string EndLengthyProcedure(IAsyncResult call) {...}

(ref http://msdn.microsoft.com/en-us/library/aa480516.aspx )

My mental model was that IIS can only have so many "things (threads?)" at once handling requests and that if you use the async techniques the page will not exhaust the pool of threads available to take requests. I thought that while the async method is running, it consume OS threads and maybe could still crush the server with activity, but IIS will assume that it doesn't need to be counted against the maximum requests that it will deal with & thus the application remains responsive.

In the comments on this question here, I got confused about if and what resources are saved with async. I'm getting the impression from that discussion no technique with the keyword "asynch" in it will save any resource with the keywords "thread" or "resource" in it. Could it be that there is some resource that is freed up for other requests and maybe I just don't have the name of it?

Part B. What is that limit, is it so high that only intense, 100s of requests per millisecond would hit it, or is it low enough that a few dozen users each running synchronous 15 minute pages could hit that limit?

Community
  • 1
  • 1
MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
  • Why would you implement something like that through a web application? In the browser paradigm, the big benefit of doing something asynch is to not block the browser from processing other requests while you wait for your operation to finish. – Maess May 23 '13 at 18:02
  • Lucian Wischik was one of the principle designers of async (along with Don Symes) and you can find his talks on this technology on his blog: http://blogs.msdn.com/b/lucian/archive/2012/03/29/talk-async-part-1-the-message-loop-and-the-task-type.aspx (Hint: async happens on a single thread, not multiple threads, so there is no limit.) – JDB May 23 '13 at 18:03
  • re: single thread vs multiple thread-- This is exactly why I said "resources", because it's like a big opaque game of gotcha to even discuss it, because askers are suppose to know the difference between a worker pool thread, OS thread, process, a fiber (a SQL thing, that allows multiple things to happen that is somehow small than a thread), and so on. – MatthewMartin May 23 '13 at 18:13
  • @maess okay, imagine it's a XHR request to an asmx. It doesn't block the browser, but that proc is still going to take 15 minutes to run. People choose to use websites independent from how long their longest transaction takes. – MatthewMartin May 23 '13 at 18:15
  • I'm not 100% sure what you are asking, but async savings is roughly equal to the amount of time a given resource would be tied up waiting minus the overhead of managing the asynchronous nature of the operation (e.g. switching threads). This may mean allowing a thread in the IIS thread pool to do work instead of waiting. IIS threading is fairly sophisticated (read about [thread agility](http://stackoverflow.com/a/657748/453277)), so it may already be shuffling things around without any intervention from you. – Tim M. May 23 '13 at 18:28
  • With regards to "Part B", in my experience IIS can process a massive (1000s per second) number of requests in both sync/async contexts. I'd suggest setting up a simple benchmark to see if it meets your needs. Frankly I'm not sure what it would do with a bunch of 15 minute synchronous requests. – Tim M. May 23 '13 at 18:33
  • You might also find [this answer](http://stackoverflow.com/a/14459475/211627) helpful. – JDB May 23 '13 at 18:46

1 Answers1

1

Lucian Wischik, one of the spec leads involved with .NET Async, described asynchronous programming using the analogy of waiters (at a restaurant).

"A waiter’s job is to wait on a table until the patrons have finished their meal. If you want to serve two tables concurrently, you must hire two waiters."
That’s not true, is it? Why? Because you don’t need two waiters! You can just use the same waiter, and share him between tables.

Talk: Async Part 1 - the message-loop, and the Task type

So, rather than spinning up new threads (which is expensive) to simply sit around and wait, you enable your primary thread to put a sort of bookmark on the request which is taking a long time. This is analogous to allowing your primary waiter to check on other tables while the first table they served is busy choosing what to order or eating.

Now, if the long-running process is something your code is doing, like processing a list of items, async isn't going to save you anything. (I suppose the analogy there would be mowing lawns, in which case you'd need two mowers to mow two lawns concurrently.) Async is only useful when your code is waiting on a resource to become available or a request to be completed, such as an internet connection to be established or a query to return results. It saves you the expense and complexity associated with multi-threading.

Lucian provides an excellent talk on the subject for people who know little or nothing about asynchronous programming at the link above. While his talk focuses on async as applied by the .NET language, the theory extends to asynchronous programming in general.

Community
  • 1
  • 1
JDB
  • 25,172
  • 5
  • 72
  • 123