Asynchronous controllers in MVC

Comments

# Israel Aece said on Thursday, April 02, 2009 6:16 AM

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,

# luisabreu said on Thursday, April 02, 2009 12:39 PM

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

# Israel Aece said on Thursday, April 02, 2009 1:52 PM

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,

# Levi said on Friday, April 03, 2009 2:36 PM

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.

# luisabreu said on Friday, April 03, 2009 3:33 PM

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?

# Levi said on Friday, April 03, 2009 4:55 PM

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. :)

# Israel Aece said on Saturday, April 04, 2009 7:24 AM

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.

# luisabreu said on Saturday, April 04, 2009 8:20 AM

Hello again Levi. Thanks for the feedback!

# luisabreu said on Saturday, April 04, 2009 8:25 AM

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 :)

# Israel Aece said on Saturday, April 04, 2009 9:41 AM

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

# Levi said on Saturday, April 04, 2009 1:19 PM

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.

# luisabreu said on Sunday, April 05, 2009 4:55 AM

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)

# luisabreu said on Sunday, April 05, 2009 5:07 AM

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)

Leave a Comment

Title (required) 

Name: (required) 

Website: (optional)

Comments (required) 

Remember Me?