Qual è il vantaggio di utilizzare async con MVC5?

Qual è la differenza tra:

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);
}

e:

[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);
}

Vedo che il codice MVC ora è asincrono ma qual è la differenza. Uno offre prestazioni molto migliori dell'altro? È più facile eseguire il debug dei problemi con uno rispetto all'altro? Devo apportare modifiche ad altri controller per la mia applicazione per aggiungere Async?

Le azioni asincrone sono utili solo quando si eseguono operazioni di I / O associate come le chiamate al server remoto. Il vantaggio della chiamata asincrona è che durante l'operazione di I / O non viene utilizzato alcun thread di lavoro ASP.NET. Quindi ecco come funziona il primo esempio:

1. Quando una richiesta raggiunge l'azione, ASP.NET prende un thread dal pool di thread e inizia a eseguirlo.
2. Il IdentityManager.Authentication.CheckPasswordAndSignInmetodo viene richiamato. Questa è una chiamata di blocco -> durante l'intera chiamata il thread di lavoro viene compromesso.

Ed ecco come funziona la seconda chiamata:

1. Quando una richiesta raggiunge l'azione, ASP.NET prende un thread dal pool di thread e inizia a eseguirlo.
2. La IdentityManager.Authentication.CheckPasswordAndSignInAsyncsi chiama che restituisce immediatamente. Viene registrata una porta di completamento I / O e il thread di lavoro ASP.NET viene rilasciato al pool di thread.
3. Successivamente, al termine dell'operazione, viene segnalata la porta di completamento I / O, un altro thread viene disegnato dal pool di thread per terminare la restituzione della visualizzazione.

Come puoi vedere nel secondo caso i thread di lavoro ASP.NET vengono utilizzati solo per un breve periodo di tempo. Ciò significa che ci sono più thread disponibili nel pool per servire altre richieste.

Quindi, per concludere, usa le azioni asincrone solo quando hai una vera API asincrona all'interno. Se effettui una chiamata di blocco all'interno di un'azione asincrona, ne stai uccidendo l'intero vantaggio.

Normalmente, una singola richiesta HTTP verrebbe gestita da un singolo thread, rimuovendo completamente quel thread dal pool fino a quando non viene restituita una risposta. Con il TPL, non sei vincolato da questo vincolo. Qualsiasi richiesta in arrivo avvia una continuazione con ogni unità di calcolo richiesta per calcolare una risposta in grado di essere eseguita su qualsiasi thread nel pool. Con questo modello è possibile gestire molte più richieste simultanee rispetto a ASP.Net standard.

Se si tratta di una nuova attività che verrà generata o meno e se dovrebbe essere attesa o meno. Pensa sempre a quei 70 ms, che sono ca. il max. tempo che dovrebbe richiedere qualsiasi chiamata al metodo. Se è più lungo, molto probabilmente la tua interfaccia utente non sarà molto reattiva.

Nelle applicazioni Web che vedono un gran numero di richieste simultanee all'avvio o hanno un carico eccessivo (dove la concorrenza aumenta improvvisamente), rendere asincrone queste chiamate di servizi Web aumenterà la reattività dell'applicazione. Una richiesta asincrona richiede la stessa quantità di tempo per l'elaborazione di una richiesta sincrona. Ad esempio, se una richiesta effettua una chiamata al servizio Web che richiede due secondi per essere completata, la richiesta richiede due secondi indipendentemente dal fatto che venga eseguita in modo sincrono o asincrono. Tuttavia, durante una chiamata asincrona, a un thread non viene impedito di rispondere ad altre richieste mentre attende il completamento della prima richiesta. Pertanto, le richieste asincrone impediscono l'accodamento delle richieste e la crescita del pool di thread quando sono presenti molte richieste simultanee che richiamano operazioni di lunga durata.