wake-up-neo.net

Was ist der Vorteil der Verwendung von Async mit MVC5?

Was ist der Unterschied zwischen:

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

und:

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

Ich sehe, dass der MVC-Code jetzt asynchron ist, aber was ist der Unterschied. Gibt es eine bessere Leistung als die andere? Ist es einfacher, Probleme mit dem einen zu debuggen als mit dem anderen? Sollte ich Änderungen an anderen Controllern für meine Anwendung vornehmen, um Async hinzuzufügen?

117
user1943020

Die asynchronen Aktionen sind nur nützlich, wenn Sie E/A-gebundene Vorgänge ausführen, z. B. Remote-Server-Aufrufe. Der Vorteil des asynchronen Aufrufs besteht darin, dass während des E/A-Vorgangs kein ASP.NET-Arbeitsthread verwendet wird. So funktioniert das erste Beispiel:

  1. Wenn eine Anforderung die Aktion trifft, nimmt ASP.NET einen Thread aus dem Threadpool und beginnt mit der Ausführung.
  2. Die IdentityManager.Authentication.CheckPasswordAndSignIn-Methode wird aufgerufen. Dies ist ein blockierender Aufruf -> während des gesamten Anrufs ist der Worker-Thread gefährdet.

Und so funktioniert der zweite Anruf:

  1. Wenn eine Anforderung die Aktion trifft, nimmt ASP.NET einen Thread aus dem Threadpool und beginnt mit der Ausführung.
  2. Der IdentityManager.Authentication.CheckPasswordAndSignInAsync wird aufgerufen und sofort zurückgegeben. Ein E/A-Fertigstellungsport wird registriert, und der ASP.NET-Arbeitsthread wird an den Threadpool freigegeben.
  3. Später, wenn der Vorgang abgeschlossen ist, wird der E/A-Fertigstellungsport signalisiert. Ein weiterer Thread wird aus dem Threadpool gezeichnet, um die Ansicht zurückzugeben.

Wie Sie im zweiten Fall sehen können, werden ASP.NET-Arbeitsthreads nur für kurze Zeit verwendet. Dies bedeutet, dass im Pool mehr Threads zur Verfügung stehen, um andere Anforderungen zu bedienen.

Zum Abschluss verwenden Sie asynchrone Aktionen nur, wenn Sie eine echte asynchrone API haben. Wenn Sie innerhalb einer asynchronen Aktion einen Sperranruf tätigen, beenden Sie damit den gesamten Nutzen.

162
Darin Dimitrov

Normalerweise wird eine einzelne HTTP-Anforderung von einem einzelnen Thread verarbeitet, der diesen Thread vollständig aus dem Pool entfernt, bis eine Antwort zurückgegeben wird. Mit der TPL sind Sie nicht an diese Einschränkung gebunden. Jede eingehende Anforderung startet eine Fortsetzung mit jeder Berechnungseinheit, die zum Berechnen einer Antwort erforderlich ist, die für jeden Thread im Pool ausgeführt werden kann. Mit diesem Modell können Sie viel mehr gleichzeitige Anforderungen bearbeiten als mit Standard-ASP.Net.

Wenn es sich um eine neue Aufgabe handelt, die erzeugt wird oder nicht und ob darauf gewartet werden soll oder nicht. Denken Sie immer an diese 70 ms, was ca. die max. Zeit, die ein Methodenaufruf in Anspruch nehmen sollte. Wenn es länger dauert, wird Ihre Benutzeroberfläche höchstwahrscheinlich nicht sehr ansprechend reagieren. 

2

In Webanwendungen, bei denen beim Starten eine große Anzahl gleichzeitiger Anforderungen angezeigt wird oder deren Last unruhig wird (wobei die Parallelität plötzlich zunimmt), erhöhen die asynchronen Webdienstaufrufe das Reaktionsverhalten Ihrer Anwendung. Eine asynchrone Anforderung benötigt zur Verarbeitung dieselbe Zeit wie eine synchrone Anforderung. Wenn beispielsweise eine Anforderung einen Webdienstaufruf durchführt, für den zwei Sekunden erforderlich sind, dauert die Anforderung zwei Sekunden, unabhängig davon, ob sie synchron oder asynchron ausgeführt wird. Während eines asynchronen Aufrufs wird ein Thread jedoch nicht daran gehindert, auf andere Anforderungen zu antworten, während er darauf wartet, dass die erste Anforderung abgeschlossen ist. Daher verhindern asynchrone Anforderungen das Anfordern von Warteschlangen und das Wachstum des Thread-Pools, wenn viele gleichzeitige Anforderungen vorhanden sind, die lang andauernde Vorgänge aufrufen.

0
Muhammad Essa