Asynchronous controllers in MVC

re: Asynchronous controllers in MVC

luisabreu — Sun, 05 Apr 2009 10:07:52 GMT

btw, I thought I'd add this link to the discussion: blogs.msdn.com/.../windows-i-o-threads-vs-managed-i-o-threads.aspx

It seems like managed IO threads aren't really equivalent to unmanaged IO threads. I think this discussion has just made me realize that I need to really start studying multithreading (which was one of my objectives to this year)

re: Asynchronous controllers in MVC

luisabreu — Sun, 05 Apr 2009 09:55:11 GMT

Guys, thanks for the great discussion. Levi, I believe that Israel has a point: it would be probably a good idea to add a note saying that you shouldn't be delegating work to the threading pool during an async action (I believe that an additional note to the doc would be all that is needed to warn people about it)

re: Asynchronous controllers in MVC

Levi — Sat, 04 Apr 2009 18:19:15 GMT

Hi Israel -

Code that spawns off a worker thread and calls Thread.Sleep() is fairly common in writing sample code for Async patterns, but you wouldn't actually go off and do this in the real world. :) It's just a sample showing that everything works; it's not best practice. The other samples (the ones that use RegisterTask) are what you should be focusing on, as they don't use the ThreadPool.

re: Asynchronous controllers in MVC

Israel Aece — Sat, 04 Apr 2009 14:41:21 GMT

Hello Luis,

You can use ADO.NET 2.0 async methods, or invoke WebServices via BeginXXX/EndXXX methods inside of async controller method. These operations already use IO thread to process.

LINQ To SQL doesn't support async execution so, envolve this execution via delegates, don't provide any benefits.

The problem is that the sample is using the ThreadPool, "stealing" threads from ThreadPool.

Bye

re: Asynchronous controllers in MVC

luisabreu — Sat, 04 Apr 2009 13:25:56 GMT

Hello Israel. To be honest, I've just given a quick glance at the async doc, so I'll have to go back to it again and see the code that they're showing.

I'm still unsure on why you'd want to use IO threads for doing the work *if* it's not IO related...btw, you can use PLINQ for making your sync actions async...god, only 30 secs looking at multithreading and my head is already hurting :)

re: Asynchronous controllers in MVC

luisabreu — Sat, 04 Apr 2009 13:20:45 GMT

Hello again Levi. Thanks for the feedback!

re: Asynchronous controllers in MVC

Israel Aece — Sat, 04 Apr 2009 12:24:29 GMT

Hi Luis,

I think that MVC uses the thread from the ThreadPool to process request and, in sample that exists in document of the Async Controller, it uses the ThreadPool again. IMHO, I believe that there are no benefits in this case. The main purpose of async pages of WebForm is to leave threads to process "light" request, where IO work isn't involved.

Maybe, you can combine AsyncController with Wintellect's CallbackThreadPool to use IO Threads, like I showed here: weblogs.pontonetpt.com/.../28605.aspx, leaving thread to serve another request while you executes IO task.

Best Regards.

re: Asynchronous controllers in MVC

Levi — Fri, 03 Apr 2009 21:55:46 GMT

We designed the AsyncController with the intent that action method authors would delegate work to components that internally used I/O completion ports, as you mentioned. There probably won't be any benefit to using the AsyncController if all of your work is performed on ThreadPool threads, since you'll be pegging the CPU anyway and IIRC you'll be using the same ThreadPool that ASP.NET uses to respond to requests.

Now, if you were a power user and really knew what you were doing, I suppose you could maintain your own ThreadPool (separate from ASP.NET's and the CLR's) and have your async methods delegate into *that*. In general I'd not recommend this, but if you were careful about what kind of work you posted to that ThreadPool then you could probably make some fairly strong performance guarantees. But I try not to play around too much in black magic territory. :)

re: Asynchronous controllers in MVC

luisabreu — Fri, 03 Apr 2009 20:33:20 GMT

Ah, the old IO/worker thread issues...Ok, I recall that IIS 6 introduced some changes to this and all ASP.NET requests are now handled by worker threads (instead of IO threads, like happened with IIS 5). If this is correct, then I'd go as far as saying that async actions will only be useful when you're doing a long action which involves delegating to IO threads (ex.: web service calls, async database access - I'm under the impression that completion ports are used for async db access introduced by .NET 2.0 - etc.). what do you guys think? are there any benefits in doing any async work if IO is not involved?

re: Asynchronous controllers in MVC

Levi — Fri, 03 Apr 2009 19:36:22 GMT

All ASP.NET requests begin on a thread pulled from the ThreadPool. WebForms and MVC are not exceptional in this regard. Because of this, you should never call a blocking method from your code. If you do, then using async will actually hurt performance rather than help it because of the overhead involved with processing async requests.

The trick is that you're supposed to keep the logic that's executing on this thread very short. From within your action method, kick off a request to an async operation that uses an I/O completion port for its work. Then the thread servicing the action method returns back to the ThreadPool very quickly, and it's free to service another request.

re: Asynchronous controllers in MVC

Israel Aece — Thu, 02 Apr 2009 18:52:29 GMT

Hi Luis,

ASP.NET WebForms uses ThreadPool threads to serve requests. When we have a request that makes a heavy IO task (like databases, web services, etc.), it blocks this thread until finalize the task.

So, the main benefit of the Async Pages (in WebForms), is that the async process will run in an IO thread, leaving ThreadPool to serve another requests.

But, in a quickly read in this paper, I saw that AsyncController uses the ThreadPool, not an IO thread.

Att,

re: Asynchronous controllers in MVC

luisabreu — Thu, 02 Apr 2009 17:39:20 GMT

hum...not following...can you give more details on what you're saying?

re: Asynchronous controllers in MVC

Israel Aece — Thu, 02 Apr 2009 11:16:17 GMT

Hi Luis,

Nice stuff. But, in a quickly read in this paper, I saw that AsyncController uses the ThreadPool. So, you can combine the controller with Wintellect CallbackThreadPool to use IO Threads.

Att,