Was ist der Vorteil der Verwendung von Async mit MVC5?

Question

Was ist der Unterschied zwischen ist:

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 das MVC-Code jetzt hat async aber was ist der Unterschied. Gibt es eine bessere Leistung als die andere? Ist es einfacher, Probleme mit einem zu debuggen als mit dem anderen? Sollte ich Änderungen an anderen Controllern vornehmen, damit meine Anwendung Async hinzufügen kann?

Answer 1

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

Wenn eine Anfrage die Aktion trifft, nimmt ASP.NET einen Thread aus dem Thread-Pool und startet die Ausführung.

Die Methode IdentityManager.Authentication.CheckPasswordAndSignIn wird aufgerufen. Dies ist ein blockierender Anruf -> während des gesamten Anrufs wird der Worker-Thread in Gefahr gebracht.

Und hier ist, wie der zweite Aufruf funktioniert:

1. Wenn eine Anforderung die Aktion erfolgreich ist, nimmt ASP.NET einen Thread aus dem Threadpool und startet ihn ausführt.
2. Die IdentityManager.Authentication.CheckPasswordAndSignInAsync wird aufgerufen, die sofort zurückgibt. Ein E/A-Abschlussport ist registriert und der ASP.NET-Arbeitsthread wird für den Threadpool freigegeben.
3. Später, wenn die Operation abgeschlossen ist, wird der E/A-Abschluss-Port signalisiert, ein weiterer Thread wird aus dem Thread-Pool gezogen, um die Rückkehr der Ansicht zu beenden.

Wie Sie im zweiten Fall sehen können ASP.NET Worker-Threads nur für einen kurzen Zeitraum verwendet werden. Dies bedeutet, dass mehr Threads im Pool für das Bedienen anderer Anfragen verfügbar sind.

Also abschließend, verwenden Sie asynchrone Aktionen nur, wenn Sie eine echte async API innerhalb haben. Wenn Sie innerhalb einer asynchronen Aktion einen blockierenden Anruf tätigen, bringen Sie den gesamten Vorteil davon zum Erliegen.

Answer 2

Normalerweise wird eine einzelne HTTP-Anfrage von einem einzelnen Thread bearbeitet, wobei dieser Thread vollständig aus dem Pool entfernt wird, bis eine Antwort zurückgegeben wird. Mit der TPL sind Sie nicht an diese Einschränkung gebunden. Jede Anfrage, die hereinkommt, beginnt eine Fortsetzung mit jeder Berechnungseinheit, die erforderlich ist, um eine Antwort zu berechnen, die in der Lage ist, auf irgendeinem Thread in dem Pool auszuführen. Mit diesem Modell können Sie viel mehr gleichzeitige Anfragen als mit Standard ASP.Net verarbeiten.

Wenn es eine neue Aufgabe ist, die erzeugt wird oder nicht, und wenn sie erwartet werden sollte oder nicht. Denken Sie immer an diese 70 ms, die ca. die max. Zeit, die ein Methodenaufruf dauern sollte. Wenn es länger ist, dann wird Ihre Benutzeroberfläche wahrscheinlich nicht sehr reaktionsschnell sein.

Answer 3

In Webanwendungen, die eine große Anzahl gleichzeitiger Anfragen beim Start sehen oder eine stoßartige Auslastung aufweisen (bei gleichzeitiger Erhöhung des gleichzeitigen Zugriffs), wird die Reaktionsfähigkeit Ihrer Anwendung durch die asynchronen Webdienstaufrufe erhöht. Eine asynchrone Anforderung dauert genauso lange wie eine synchrone Anforderung. Beispiel: Wenn eine Anfrage einen Web-Service-Anruf tätigt, für den zwei Sekunden benötigt werden, dauert es zwei Sekunden, ob die Anfrage 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 auf die Beendigung der ersten Anforderung wartet. Daher verhindern asynchrone Anforderungen das Anforderungs-Queuing und das Wachstum des Thread-Pools, wenn viele gleichzeitige Anforderungen lang andauernde Vorgänge aufrufen.