What is the advantage of using async with MVC5?

What is the difference between:

public ActionResult Login(LoginViewModel model, string returnUrl)
{
    if (ModelState.IsValid)
    {
        IdentityResult result = IdentityManager.Authentication.CheckPasswordAndSignIn(AuthenticationManager, model.UserName, model.Password, model.RememberMe);
        if (result.Success)
        {
            return Redirect("~/home");
        }
        else
        {
            AddErrors(result);
        }
    }
    return View(model);
}

and:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Login(LoginViewModel model, string returnUrl)
{
    if (ModelState.IsValid)
    {
        IdentityResult result = await IdentityManager.Authentication.CheckPasswordAndSignInAsync(AuthenticationManager, model.UserName, model.Password, model.RememberMe);
        if (result.Success)
        {
            return Redirect("~/home");
        }
        else
        {
            AddErrors(result);
        }
    }
    return View(model);
}

I see that the MVC code now has async but what is the difference. Does one give much better performance than the other? Is it easier to debug problems with one than the other? Should I make changes to other controllers for my application to add Async ?

The async actions are useful only when you are performing I/O bound operations such as remote server calls. The benefit of the async call is that during the I/O operation, no ASP.NET worker thread is being used. So here's how the first example works:

1. When a request hits the action, ASP.NET takes a thread from the thread pool and starts executing it.
2. The IdentityManager.Authentication.CheckPasswordAndSignIn method is invoked. This is a blocking call -> during the entire call the worker thread is being jeopardized.

And here's how the second call works:

1. When a request hits the action, ASP.NET takes a thread from the thread pool and starts executing it.
2. The IdentityManager.Authentication.CheckPasswordAndSignInAsync is called which returns immediately. An I/O Completion Port is registered and the ASP.NET worker thread is released to the thread pool.
3. Later when the operation completes, the I/O Completion port is signaled, another thread is drawn from the thread pool to finish returning the view.

As you can see in the second case ASP.NET worker threads are used only for a short period of time. This means that there are more threads available in the pool for serving other requests.

So to conclude, use async actions only when you have a true async API inside. If you make a blocking call inside an async action, you are killing the whole benefit of it.

Normally, a single HTTP request would be handled by a single thread, completely removing that thread from the pool until a response is returned. With the TPL, you are not bound by this constraint. Any request that come in starts a continuation with each unit of computation required to calculate a response able to execute on any thread in the pool. With this model, you can handle many more concurrent requests than with standard ASP.Net.

If it is some new task that will be spawned, or not, and if it should be awaited or not. Always think about those 70 ms, which is approx. the max. time that any method call should take. If its longer, then your UI will most probably not feel very responsiveness.