up vote 2 down vote favorite
1

I'm new to using AngularJS with MVC 5 and I've been looking at using Web API with AngularJS since it seems like a good solution for loading data into your client side models.

However I've noticed that quite a few guides use async actions that returns Task<Model> and I don't understand what benefit this gives you over using just standard Web API actions (examples: http://monox.mono-software.com/blog/post/Mono/233/Async-upload-using-angular-file-upload-directive-and-net-WebAPI-service/ and http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/build-a-single-page-application-%28spa%29-with-aspnet-web-api-and-angularjs).

Since these calls to Web API are asynchronous anyway I don't know why we need to make these method calls asynchronous. Wouldn't it be better to use just standard Web API calls?

I don't know if stackoverflow is the right place for this but I was hoping for an explanation on why calls are done this way.

share|improve this question
2  
The point of async methods in a server is just to avoid wasting threads, for scalability. Read blog.slaks.net/2014-12-23/parallelism-async-threading-explai‌​ned – SLaks Jan 30 '15 at 14:54
up vote 5 down vote accepted

The benefit of async-await on the server is scalability and performance. When you replace synchronous (blocking) operations with asynchronous (non-blocking) ones you free up threads that were previously blocked waiting which you can use to handle other requests concurrently.

async-await enables you to do more with less resources.

Let's assume we have this synchronous method:

public void Process()
{
    for (int i = 0; i < 1000; i++)
    {
        Math.Sqrt(i);
    }

    Thread.Sleep(3000); // sync I/O
}

By making it async:

public async Task ProcessAsync()
{
    for (int i = 0; i < 1000; i++)
    {
        Math.Sqrt(i);
    }

    await Task.Delay(3000) // async I/O
}

We can use a single thread to process multiple requests of the same method because the thread handling the request is freed up when you await the asynchronous operation.

share|improve this answer
    
I understand what async-await does what I don't understand is why in some of those methods they've bothered to use it in where I can't see any benefit in it. For example in one method they await on an async call and all the rest of the method does is check to see if the result is null and if it is returns a value and if not returns a different value. So since you aren't actually doing any other operations except waiting for the asynchronous call to finish why bother to use await there at all? – Serberuss Jan 30 '15 at 15:03
    
@Serberuss How do you know there aren't any other operations? Just imagine you get a request from a different client at the exact time. Most Web API applications aren't confined to a single synchronous client. – i3arnon Jan 30 '15 at 15:06
    
Perhaps I'm getting it confused with synchronous web action calls then since I never see async-await used there for things like repository calls, and I think of it similarly to web service calls except that it can be used asynchronously client side – Serberuss Jan 30 '15 at 15:13
    
Using async-await only make sense when the operation is truly asynchronous (mostly I/O). If you have the option to use an async version of these operations you would be able to handle more requests concurrently. – i3arnon Jan 30 '15 at 15:15
    
Ok makes a bit more sense. I won't bother you with too many questions thanks a lot for your explanations – Serberuss Jan 30 '15 at 15:33
up vote 1 down vote

Async await on the server side is not to enable/enhance asynchronous XMLHttpRequests (AJAX calls). It is to enable the await keyword and handling of methods that return Tasks in lower-level framework code and your server-side code, should you choose to implement any. This example comes to mind:

The underlying Web API's controller dispatcher spins up a controller in response to a request and and tells it to go execute an action. It then needs to look at the response of that and take action depending on the result (error, etc.). If it executes that dispatch synchronously, the thread is blocked by the dispatcher waiting for the action to complete, when it doesn't have to be. In an async context, that dispatcher can await the response from the controller, and the thread is freed up for other tasks to run. When the original controller's action is done, any free thread can pick up where the first thread left off and handle the rest of the dispatch.

share|improve this answer
up vote 0 down vote

To give another illustrative example:

Imagine 2 requests, one of which gets caught up in waiting for database for 2 seconds and the other gets caught up in application logic for 2 seconds.

Without async, at 1 second into the requests, 2 threads are in use.

With async (implemented all the way down to the database call), at 1 second into the requests, 1 thread is in use, processing application logic. The other request is in an await state (no thread used).

Both requests will take 2 seconds, but in the async scenario the number of active threads is reduced for some of the request duration

share|improve this answer
    
So you're saying you won't notice anything from a client's point of view but it's more efficient for the server to do this? I'm still not completely sure why I haven't seen this in synchronous calls to MVC action where database calls are made, or in WPF applications. – Serberuss Jan 30 '15 at 15:32
    
Yes, it affects thread pooling and in .net the memory impact of a thread is maybe around 1mb per active thread. So you would only really notice at the level of hundreds of concurrent requests. – Kaido Jan 30 '15 at 15:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.