Leveraging the Power of Asynchrony in ASP.NET [转]

Asynchronous programming has had a lot of attention in the last couple of years and there are two key reasons for this: First it helps in providing a better user experience by not blocking the UI thread which avoids the hanging of the UI screen until the processing is done, and second, it helps in scaling up the system drastically without adding any extra hardware.

But writing asynchronous code and managing the thread gracefully was a tedious task. But as the benefits are tremendous, many new technologies and old technologies have started embracing it. Microsoft has also invested a lot in it since .NET 4.0 and then in .NET 4.5, they made it simpler than ever with the introduction of async and the await keyword.

However, asynchrony has been usable in ASP.NET since the beginning but has never gotten the required attention. And given the way requests are handled by ASP.NET and IIS, asynchrony could be much more beneficial and we can easily scale up our ASP.NET applications drastically. With the introduction of new programming constructs like async and await, it’s high time that we start leveraging the power of asynchronous programming.

In this post, we are going to discuss the way requests are processed by IIS and ASP.NET, then we will see the places where we can introduce asynchrony in ASP.NET and discuss various scenarios where we can gain maximum benefits from it.

How are requests handled?

Every ASP.NET request has to go through IIS then is ultimately handled by ASP.NET handlers. A request is first received by IIS and after initial processing, forwards to ASP.NET which actually handles the request (for an ASP.NET request) and generates the response. This response is then sent back to the client via IIS. IIS has some worker threads that are responsible for taking the request from the queue and executing IIS modules and then forwarding the request to ASP.NET queue. ASP.NET doesn’t create any thread or own any thread pool to handle the request, instead it uses the CLR thread pool and gets the thread from there to handle the requests. The IIS module calls ThreadPool.QueueUserWorkItem which queues the request to CLR worker threads. As we know, the CLR thread pool is managed by CLR and self-tuned (meaning it creates/destroys the threads based on need). Also, we should keep in mind that creating and destroying a thread is always a heavy task and that’s why this pool allows us to reuse the same thread for multiple tasks. So let’s see pictorially the way a request gets processed.

In the above pic, we can see that a request is first received by HTTP.sys and added in the queue of the corresponding application pool at kernel level. One IIS worker thread takes the request from the queue and passes it to the ASP.NET queue after its processing. The request may get returned from IIS itself if it is not an ASP.NET Request. A thread from the CLR thread pool gets assigned to the thread that’s responsible for processing the request.

When should Asynchrony be used in ASP.NET?

Any request can broadly be divided in two types:

1-     CPU Bound

2-     I/O Bound

A CPU bound request needs CPU time and is executed in same process, while I/O bound requests are blocking in nature and dependent on other modules which do the I/O operations and return the response. Blocking requests are one of the major roadblocks for high scalable applications and in most of our web application we been wasting lots of time while waiting for I/O operations. These are the following scenarios where asynchrony should be used:

1-     For I/O Bound requests including

1. Database access
2. Reading/Writing Files
3. Web Service calls
4. Accessing Network resources

2-     Event driven requests like SignalR

3-     Where we need to get the data from multiple sources

Let’s create an example where we would create a simple Synchronous Page and then will convert it to an asynchronous page. For this example, I have put a delay of 1000ms (to mimic some heavy calls like Database/web service calls, etc.) and also downloaded one page using the WebClient as follows:

         protected void Page_Load(object sender, EventArgs e)
        {
            System.Threading.Thread.Sleep();
            WebClient client = new WebClient();
            string downloadedContent = client.DownloadString("https://msdn.microsoft.com/en-us/library/hh873175%28v=vs.110%29.aspx");
            dvcontainer.InnerHtml = downloadedContent;
        }

Now we will convert this page to an asynchronous page. There are mainly three steps involved here

1. Change it to asynchronous page by adding Async = true in the page directive as follows:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Home.aspx.cs" Inherits="AsyncTest.Home" Async="true" AsyncTimeout="3000" %>

I have also added AsyncTimeout (which is optional) but we can define based on our requirement.

1. Convert the method to an Asynchronous one. Here we convert Thread.Sleep and client.DownloadString to the asynchronous method as follows:

private async Task AsyncWork()
        {
            await Task.Delay();

             WebClient client = new WebClient();

             string downloadedContent = await client.DownloadStringTaskAsync("https://msdn.microsoft.com/en-us/library/hh873175%28v=vs.110%29.aspx ");

             dvcontainer.InnerHtml = downloadedContent;

        }

1. Now we can call this method directly at Page_Load and make it asynchronous as follows:

protected async void Page_Load(object sender, EventArgs e)

{

await AsyncWork();

}

But here Page_Load returns the type is async void which should be avoided in almost all cases. As we know the flow of the page life cycle, Page_Load is a part of life cycle and if we set it as async then there could be scenarios and other events where the lifecycle may get executed even if the page load is still running. It is highly recommended we use RegisterAsyncTask which allows us to register the asynchronous method which is executed during the lifecycle while it is most appropriate and avoids any issue. So we should write it as follows:

protected void Page_Load(object sender, EventArgs e)

{

RegisterAsyncTask(new PageAsyncTask(AsyncWork));

}

Now we have converted our page as asynchronous and it won’t be a blocking request.

I deployed both applications on IIS 8.5 and tested them with burst load. For the same machine configuration, the synchronous page was able to take just 1,000 requests in 2-3 seconds while the asynchronous page was able to serve more than 2,200 requests. After that, we started getting Timeout or Server Not Available errors. Although the average request processing time isn’t much different, we were able to serve more than 2X the requests just by making the page asynchronous. If that isn’t proof we should leverage the power of asynchronous programming, I don’t know what is!

There are some other places where we can introduce asynchrony in ASP.NET too:

1-      By writing asynchronous modules

2-      By writing Asynchronous HTTP Handlers using IHttpAsyncHandler or HttpTaskAsyncHandler

3-      Using web sockets or SignalR

Conclusion

In this post, we discussed asynchronous programming and saw that with the help of new async and await keywords, writing asynchronous code is very easy. We covered the topic of request processing by IIS and ASP.NET and discussed the scenarios where asynchrony can be more fruitful, and we also created a simple example and discussed the benefits of asynchronous pages. Last we explored some places where asynchrony can be leveraged in ASP.NET.

Thanks for reading!

http://news.oneapm.com/advantage/

http://www.infragistics.com/community/blogs/brijmishra/archive/2015/10/28/leveraging-the-power-of-asynchrony-in-asp-net.aspx