Jaka jest zaleta używania async z MVC5?

Jaka jest różnica pomiędzy:

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

i:

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

Widzę, że kod MVC ma teraz asynchroniczny, ale jaka jest różnica. Czy jeden zapewnia znacznie lepszą wydajność niż drugi? Czy łatwiej jest debugować problemy z jednym niż drugim? Czy powinienem wprowadzić zmiany w innych kontrolerach, aby moja aplikacja mogła dodać Async?

Akcje asynchroniczne są przydatne tylko podczas wykonywania operacji związanych z we / wy, takich jak wywołania serwera zdalnego. Zaletą wywołania asynchronicznego jest to, że podczas operacji we / wy nie jest używany żaden wątek roboczy ASP.NET. Oto jak działa pierwszy przykład:

1. Gdy żądanie trafia w akcję, ASP.NET pobiera wątek z puli wątków i rozpoczyna jego wykonywanie.
2. IdentityManager.Authentication.CheckPasswordAndSignInMetoda jest wywoływana. To jest wywołanie blokujące -> podczas całego połączenia wątek roboczy jest zagrożony.

A oto jak działa drugie połączenie:

1. Gdy żądanie trafia w akcję, ASP.NET pobiera wątek z puli wątków i rozpoczyna jego wykonywanie.
2. Wywoływana IdentityManager.Authentication.CheckPasswordAndSignInAsyncjest funkcja, która natychmiast powraca. Rejestrowany jest port zakończenia we / wy, a wątek roboczy ASP.NET jest zwalniany do puli wątków.
3. Później, gdy operacja zostanie zakończona, zostanie zasygnalizowany port zakończenia we / wy, inny wątek jest rysowany z puli wątków, aby zakończyć zwracanie widoku.

Jak widać w drugim przypadku wątki robocze ASP.NET są używane tylko przez krótki czas. Oznacza to, że w puli dostępnych jest więcej wątków do obsługi innych żądań.

Podsumowując, używaj akcji asynchronicznych tylko wtedy, gdy masz wewnątrz prawdziwy interfejs API asynchroniczny. Jeśli wykonasz połączenie blokujące w akcji asynchronicznej, zabijasz całą jego korzyść.

Zwykle pojedyncze żądanie HTTP byłoby obsługiwane przez jeden wątek, całkowicie usuwając ten wątek z puli, aż do zwrócenia odpowiedzi. Dzięki TPL nie jesteś związany tym ograniczeniem. Każde przychodzące żądanie rozpoczyna kontynuację z każdą jednostką obliczeniową wymaganą do obliczenia odpowiedzi, która może zostać wykonana w dowolnym wątku w puli. Dzięki temu modelowi możesz obsłużyć znacznie więcej jednoczesnych żądań niż w przypadku standardowego ASP.Net.

Czy pojawi się jakieś nowe zadanie, czy nie, i czy należy na nie czekać, czy nie. Zawsze myśl o tych 70 ms, czyli ok. max. czas, jaki powinno zająć wywołanie metody. Jeśli jest dłuższy, Twój interfejs użytkownika najprawdopodobniej nie będzie reagował zbyt szybko.

W aplikacjach internetowych, które widzą dużą liczbę równoczesnych żądań podczas uruchamiania lub mają gwałtowne obciążenie (gdzie współbieżność nagle wzrasta), asynchroniczne wywoływanie usług sieci Web zwiększy szybkość reakcji aplikacji. Przetwarzanie żądania asynchronicznego zajmuje tyle samo czasu, co żądanie synchroniczne. Na przykład, jeśli żądanie powoduje wywołanie usługi sieci Web, które wymaga dwóch sekund, aby zakończyć, żądanie zajmuje dwie sekundy, niezależnie od tego, czy jest wykonywane synchronicznie, czy asynchronicznie. Jednak podczas wywołania asynchronicznego wątek nie jest blokowany przed odpowiadaniem na inne żądania, gdy czeka na zakończenie pierwszego żądania. Dlatego żądania asynchroniczne zapobiegają kolejkowaniu żądań i wzrostowi puli wątków, gdy istnieje wiele współbieżnych żądań, które wywołują długotrwałe operacje.