共用方式為

Should my database calls be Asynchronous Part II

  • 發行項

Update 28 November 2012: The combination of await, async, and the Task object makes it much easier for you to write asynchronous code in .NET 4.5.  Now that EF 6 is supporting Async Query and Save, you should take advantage of asynchronous programming. (As of this update, EF6 is not released so don’t use it just yet for production code).  When this blog was first written, it was much more difficult to wire asynchronous code. See my two async tutorials:

A frequent question in the forums and internally at Microsoft is Should my database calls be Asynchronous?  My short answer to this; if you have to ask, probably no. My blog entry on the question, Should my database calls be Asynchronous? is still relevant and should be read by anyone considering asynchronous web programming. ASP.NET MVC 4 will probably include Task and Task<TResult> support for AsyncController Classes, making asynchronous web programming simpler (but still very complex). See  the roadmap for ASP.NET MVC 4 on CodePlexfor more information. While I know of several customers successfully using the Asynchronous Controller in ASP.NET MVC, I know of more failed attempts.

The ASP.NET/IIS guru Thomas Marquardt countered my negative comments on asynchronous web programming when he wrote:

Back-end web services, which are distributed across the globe, are often used by web front ends. These web services can exhibit quite a bit of latency (one hundred to hundreds of milliseconds), and that latency may vary quite a bit, as is common with HTTP.  

For this scenario, I think your web front end will be more reliable and responsive if it makes those web service calls asynchronously. This is primarily due to the fact that the CLR ThreadPool is very unresponsive to latency—it injects new threads at a rate of about 2 per second and so concurrency can be “stuck” very low, and the web service calls will be “serialized” on a few threads, while the other web page requests wait for an available thread. If you make the web service calls asynchronously, you’ll enable a bunch of front end requests to execute concurrently, and the user experience will be much better because they’ll get their response about as fast as the web service back-end can respond.

There is simply no way you can configure the CLR ThreadPool (in any of the current releases) to obtain good performance when the back-end calls have variable latency (in the range of 20-200 ms), the front end is seeing hundreds or thousands of concurrent requests, and you’re making the back-end calls synchronously. You have to make the back-end calls asynchronously.

Another benefit of asynchronous programming in a web page is the ability to do work in parallel. For example, if you need to call 2 web services independently, and each takes 200 milliseconds to respond. If you make the calls synchronously, it takes ~400 milliseconds, but if you make them asynchronously it takes ~200 milliseconds.

Asynchronous programming is definitely complex, but the new C# functionality (await, etc) attempts to reduce this for the user.   Just don’t try to debug Smile

Comments

  • Anonymous
    May 28, 2012
    Are there any existing tools which help you to stress test and compare async and non-async code in ASP.NET MVC / Web API scenario?