Does async and await increase performance of an ASP.Net application

Question

I recently read an article about c#-5 and new & nice asynchronous programming features . I see it works greate in windows application. The question came to me is if this feature can increase ASP.Net performance?

consider this two psudo code:

public T GetData()
{
    var d = GetSomeData();
    return d;
}

and

public async T GetData2()
{
    var d = await GetSomeData();   
    return d;
}

Has in an ASP.Net appication that two codes difference?

thanks

Mascle

Answer 1

Well for a start your second piece of code would return Task<T> rather than T. The ultimate answer is "it depends".

If your page needs to access multiple data sources, it may make it simpler to parallelize access to those sources, using the result of each access only where necessary. So for example, you may want to start making a long-running data fetch as the first part of your page handling, then only need the result at the end. It's obviously possible to do this without using async/await, but it's a lot simpler when the language is helping you out.

Additionally, asynchrony can be used to handle a huge number of long-running requests on a small number of threads, if most of those requests will be idle for a lot of the time - for example in a long-polling scenario. I can see the async abilities being used as an alternative to SignalR in some scenarios.

The benefits of async on the server side are harder to pin down than on the client side because there are different ways in which it helps - whereas the "avoid doing work on the UI thread" side is so obvious, it's easy to see the benefit.

Don't forget that there can be a lot more to server-side coding than just the front-end. In my experience, async is most likely to be useful when implementing RPC services, particularly those which talk to multiple other RPC services.

As Pasi says, it's just syntactic sugar - but I believe that it's sufficiently sweet sugar that it may well make the difference between proper asynchronous handling being feasible and it being simply too much effort and complexity.

Marlenemarler

Answer 2

Define 'performance'.

Ultimately the application is going to be doing the same amount of work as it would have done synchronously, it's just that the calling thread in the asynchronous version will wait for the operation to complete on another, whereas in the synchronous model it's the same thread performing the task.

Ultimately in both cases the client will wait the same amount of time before seeing a response from the web server and therefore won't notice any difference in performance.

If the web request is being handled via an asynchronous handler, then, again, the response will still take the same amount of time to return - however, you can decrease the pressure on the thread pool, making the webserver itself more responsive in accepting requests - see this other SO for more details on that.

Crissycrist

Answer 3

Since the code is executed on the server and the user will still have to wait for the response, the question is like - does async call go faster than sync call.

Well, that depends mostly on the server implementation. For IIS and multiple number of users, too many threads would be spawned per user (even without async) and async would be inefficient. But in case of small amount of users it should be faster.

One way to see is to try out.

Overmantel

Answer 4

No. These are purely syntactic sugar and make your job as a programmer easier by allowing writing simple code and read code simply when you fix the bugs.

It does allow simpler approach to loading data without blocking UI, so in a way yes, but not really.

Lundy

At the point where it makes the difference between "asynchrony is too hard; let's use one thread per request" and "asynchrony is easy - let's do things more efficiently" it will have an impact. Just because it can all be done manually doesn't mean it can't be used to have a practical effect on performance. – Marlenemarler

Answer 5

It would only increase performance if you needed to do multiple things, that can all be done without the need for any other information. Otherwise you may as well just do them in sequence.

In terms of your example, the answer is no. The page needs to wait for each one regardless.

Platas

Suppose the "thing" you need to do is wait for up to 5 minutes for a chat message. Do you want each request tying up a thread for that long? How many users do you want to be able to support on a single server? (Think of a long-polling AJAX request.) – Marlenemarler

Wouldn't polling for a chat message just require that the client poll, check message, then return with yes or no. I couldn't see how a thread would sit their waiting for it. I would make that based on a timer. Unless I misunderstood your question? – Platas

The point of long-polling is to issue a request which can return immediately when there's data - so the client doesn't need to poll every 30 seconds or so. You get quicker feedback, fewer requests, but you need to be able to handle very long, persistent connections. – Marlenemarler

I have never come across a long-polling scenario as yet (in my work) but yes I can see your point for those situations :) – Platas