Używanie metod asynchronicznych w ASP.NET MVC 4

Autor : Rick Anderson

Ten samouczek zawiera podstawowe informacje na temat tworzenia asynchronicznej aplikacji internetowej ASP.NET MVC przy użyciu programu Visual Studio Express 2012 for Web, która jest bezpłatną wersją programu Microsoft Visual Studio. Możesz również użyć programu Visual Studio 2012.

Kompletny przykład jest udostępniany na potrzeby tego samouczka w witrynie GitHub https://github.com/RickAndMSFT/Async-ASP.NET/

Klasa Controller MVC 4 ASP.NET w połączeniu z .NET 4.5 umożliwia pisanie asynchronicznych metod akcji, które zwracają obiekt typu Task<ActionResult>. Program .NET Framework 4 wprowadził asynchroniczne pojęcie programowania określane jako zadanie i ASP.NET MVC 4 obsługuje zadanie. Zadania są reprezentowane przez typ zadania i powiązane typy w przestrzeni nazw System.Threading.Tasks . Program .NET Framework 4.5 opiera się na tej asynchronicznej obsłudze słów kluczowych await i asynchronicznych , które sprawiają, że praca z obiektami zadań jest znacznie mniej złożona niż poprzednie metody asynchroniczne. Słowo kluczowe await to skrót składniowy wskazujący, że fragment kodu powinien asynchronicznie czekać na inny fragment kodu. Słowo kluczowe asynchroniczne reprezentuje wskazówkę, której można użyć do oznaczania metod jako metod asynchronicznych opartych na zadaniach. Kombinacja funkcji await, async i obiektu Task znacznie ułatwia pisanie kodu asynchronicznego na platformie .NET 4.5. Nowy model metod asynchronicznych jest nazywany asynchronicznym wzorcem asynchronicznym opartym na zadaniach (TAP). W tym samouczku założono, że masz pewną znajomość asynchronicznego programowania z użyciem słów kluczowych await i async oraz przestrzeni nazw Task.

Aby uzyskać więcej informacji na temat używania słów kluczowych await i async oraz przestrzeni nazw Task, zobacz następujące odwołania.

Jak przetwarzane są żądania przez pulę wątków

Na serwerze internetowym platforma .NET Framework obsługuje pulę wątków używanych do obsługi żądań ASP.NET. Po nadejściu żądania zostanie wysłany wątek z puli w celu przetworzenia tego żądania. Jeśli żądanie jest przetwarzane synchronicznie, wątek, który przetwarza żądanie, jest zajęty podczas przetwarzania żądania, a ten wątek nie może obsłużyć innego żądania.

Może to nie być problem, ponieważ pula wątków może być wystarczająco duża, aby pomieścić wiele zajętych wątków. Jednak liczba wątków w puli wątków jest ograniczona (domyślna wartość maksymalna dla platformy .NET 4.5 to 5000). W dużych aplikacjach z wysoką współbieżnością długotrwałych żądań wszystkie dostępne wątki mogą być zajęte. Ten warunek jest nazywany głodem wątku. Po osiągnięciu tego warunku, serwer WWW kolejkuje żądania. Jeśli kolejka żądań stanie się pełna, serwer internetowy odrzuca żądania ze stanem HTTP 503 (Serwer jest zbyt zajęty). Pula wątków CLR ma ograniczenia dotyczące dodawania nowych wątków. Jeśli współbieżność jest pęknięta (oznacza to, że witryna internetowa może nagle uzyskać dużą liczbę żądań), a wszystkie dostępne wątki żądań są zajęte z powodu wywołań zaplecza z dużym opóźnieniem, ograniczona szybkość wstrzykiwania wątków może sprawić, że aplikacja będzie reagować bardzo źle. Ponadto każdy nowy wątek dodany do puli wątków wiąże się z dodatkowymi kosztami (np. 1 MB pamięci stosu). Aplikacja internetowa używająca synchronicznych metod do obsługi wywołań o dużym opóźnieniu, gdzie pula wątków rośnie do domyślnej maksymalnej wielkości 5 000 wątków w platformie .NET 4.5, zużywałaby około 5 GB więcej pamięci niż aplikacja, która może obsługiwać te same żądania przy użyciu asynchronicznych metod i tylko 50 wątków. Podczas pracy asynchronicznej nie zawsze korzystasz z wątku. Na przykład, gdy wykonasz asynchroniczne żądanie usługi sieciowej, ASP.NET nie będzie używać żadnych wątków między wywołaniem metody async a await. Użycie puli wątków do obsługi żądań z dużym opóźnieniem może prowadzić do dużego zużycia pamięci i słabego wykorzystania sprzętu serwera.

Przetwarzanie żądań asynchronicznych

W aplikacji internetowej, która obsługuje dużą liczbę równoczesnych żądań podczas uruchamiania lub doświadcza nagłego wzrostu obciążenia (gdzie współbieżność gwałtownie wzrasta), asynchroniczne wykonywanie wywołań usług internetowych zwiększa responsywność aplikacji. Żądanie asynchroniczne trwa tyle samo czasu na przetworzenie, co żądanie synchroniczne. Jeśli żądanie wykonuje wywołanie usługi internetowej, które wymaga dwóch sekund do ukończenia, żądanie trwa dwie sekundy, niezależnie od tego, czy jest wykonywane synchronicznie, czy asynchronicznie. Jednak podczas wywołania asynchronicznego wątek nie jest blokowany i może obsługiwać inne żądania w czasie oczekiwania na zakończenie pierwszego żądania. W związku z tym żądania asynchroniczne uniemożliwiają kolejkowanie żądań i wzrost puli wątków, gdy istnieje wiele współbieżnych żądań, które wywołują długotrwałe operacje.

Wybieranie metod akcji synchronicznych lub asynchronicznych

W tej sekcji wymieniono wskazówki dotyczące używania metod akcji synchronicznych lub asynchronicznych. Są to tylko wytyczne; zbadaj poszczególne aplikacje indywidualnie, aby określić, czy metody asynchroniczne pomagają w wydajności.

Ogólnie rzecz biorąc, użyj metod synchronicznych dla następujących warunków:

  • Operacje są proste lub krótkie.
  • Prostota jest ważniejsza niż wydajność.
  • Operacje to przede wszystkim operacje procesora CPU, a nie operacje obejmujące duże obciążenie dysku lub sieci. Korzystanie z metod akcji asynchronicznych w operacjach związanych z procesorem CPU nie zapewnia żadnych korzyści i powoduje większe obciążenie.

Ogólnie rzecz biorąc, użyj metod asynchronicznych dla następujących warunków:

  • Wywołujesz usługi, które mogą być używane za pomocą metod asynchronicznych i używasz platformy .NET 4.5 lub nowszej.
  • Operacje są powiązane z siecią lub wejściem/wyjściem, zamiast z procesorem.
  • Równoległość jest ważniejsza niż prostota kodu.
  • Chcesz udostępnić mechanizm, który umożliwia użytkownikom anulowanie długotrwałego żądania.
  • Gdy korzyść z przełączania wątków przewyższa koszt przełącznika kontekstu. Ogólnie rzecz biorąc, warto przekształcić metodę na asynchroniczną, jeśli metoda synchroniczna czeka na wątek żądania ASP.NET, gdy nie wykonuje żadnej pracy. Wykonując asynchroniczne wywołanie, wątek żądania ASP.NET nie jest wstrzymany, bezczynnie oczekując na ukończenie żądania usługi internetowej.
  • Testowanie pokazuje, że operacje blokujące są wąskim gardłem w wydajności strony i że IIS może obsługiwać więcej żądań, wykorzystując metody asynchroniczne do obsługi tych wywołań blokujących.

W przykładzie do pobrania pokazano, jak efektywnie używać metod akcji asynchronicznych. Udostępniony przykład został zaprojektowany w celu zapewnienia prostego pokazu programowania asynchronicznego w ASP.NET MVC 4 przy użyciu platformy .NET 4.5. Przykład nie jest przeznaczony do programowania asynchronicznego w ASP.NET MVC. Przykładowy program wywołuje metody internetowego interfejsu API ASP.NET , które z kolei wywołają metodę Task.Delay w celu symulowania długotrwałych wywołań usług internetowych. Większość aplikacji produkcyjnych nie pokaże tak oczywistych korzyści związanych z używaniem metod akcji asynchronicznych.

Niewiele aplikacji wymaga, aby wszystkie metody akcji są asynchroniczne. Często konwertowanie kilku synchronicznych metod akcji na metody asynchroniczne zapewnia najlepszy wzrost wydajności wymaganej pracy.

Przykładowa aplikacja

Przykładową aplikację można pobrać z https://github.com/RickAndMSFT/Async-ASP.NET/ witryny GitHub . Repozytorium składa się z trzech projektów:

  • Mvc4Async: projekt ASP.NET MVC 4 zawierający kod używany w tym samouczku. Wykonuje wywołania interfejsu API do usługi WebAPIpgw.
  • WebAPIpgw: projekt internetowego interfejsu Products, Gizmos and Widgets API platformy ASP.NET MVC 4, który implementuje kontrolery. Udostępnia ona dane dla projektu WebAppAsync i projektu Mvc4Async .
  • WebAppAsync: projekt ASP.NET Web Forms używany w innym samouczku.

Metoda akcji synchronicznej Gizmos

Poniższy kod przedstawia Gizmos synchroniczną metodę akcji używaną do wyświetlania listy gizmos. (W tym artykule gizmo jest fikcyjnym urządzeniem mechanicznym).

public ActionResult Gizmos()
{
    ViewBag.SyncOrAsync = "Synchronous";
    var gizmoService = new GizmoService();
    return View("Gizmos", gizmoService.GetGizmos());
}

Poniższy kod przedstawia metodę GetGizmos usługi gizmo.

public class GizmoService
{
    public async Task<List<Gizmo>> GetGizmosAsync(
        // Implementation removed.
       
    public List<Gizmo> GetGizmos()
    {
        var uri = Util.getServiceUri("Gizmos");
        using (WebClient webClient = new WebClient())
        {
            return JsonConvert.DeserializeObject<List<Gizmo>>(
                webClient.DownloadString(uri)
            );
        }
    }
}

Metoda GizmoService GetGizmos przekazuje identyfikator URI do usługi HTTP interfejsu API sieci Web ASP.NET, która zwraca listę danych gizmos. Projekt WebAPIpgw zawiera implementację internetowego interfejsu API gizmos, widget i product kontrolerów.
Na poniższej ilustracji przedstawiono widok gizmos z przykładowego projektu.

Gizmos

Tworzenie asynchronicznej metody akcji Gizmos

W przykładzie użyto nowych słów kluczowych asynchronicznych i await (dostępnych w programach .NET 4.5 i Visual Studio 2012), aby umożliwić kompilatorowi zachowanie skomplikowanych przekształceń niezbędnych do programowania asynchronicznego. Kompilator umożliwia pisanie kodu przy użyciu synchronicznych konstrukcji przepływu sterowania języka C#, a kompilator automatycznie stosuje przekształcenia niezbędne do używania wywołań zwrotnych w celu uniknięcia blokowania wątków.

Poniższy kod przedstawia metodę Gizmos synchroniczną i metodę GizmosAsync asynchroniczną. Jeśli przeglądarka obsługuje element HTML 5<mark>, zobaczysz zmiany wyróżnione na żółto w GizmosAsync.

public ActionResult Gizmos()
{
    ViewBag.SyncOrAsync = "Synchronous";
    var gizmoService = new GizmoService();
    return View("Gizmos", gizmoService.GetGizmos());
}

public async Task<ActionResult> GizmosAsync()
{
    ViewBag.SyncOrAsync = "Asynchronous";
    var gizmoService = new GizmoService();
    return View("Gizmos", await gizmoService.GetGizmosAsync());
}

Zastosowano następujące zmiany, aby umożliwić GizmosAsync asynchroniczność.

  • Metoda jest oznaczona za pomocą słowa kluczowego asynchronicznego , które nakazuje kompilatorowi generowanie wywołań zwrotnych dla części treści i automatyczne utworzenie zwracanego elementu Task<ActionResult> .
  • Element "Async" został dołączony do nazwy metody. Dołączanie "Async" nie jest wymagane, ale jest konwencją podczas pisania metod asynchronicznych.
  • Typ zwracany został zmieniony z ActionResult na Task<ActionResult>. Zwracany typ Task<ActionResult> reprezentuje bieżącą pracę i zapewnia wywołującym metodę uchwyt, za pomocą którego mogą poczekać na zakończenie operacji asynchronicznej. W takim przypadku obiekt wywołujący jest usługą internetową. Task<ActionResult> reprezentuje bieżącą pracę z wynikiem ActionResult.
  • Słowo kluczowe await zostało zastosowane do wywołania usługi internetowej.
  • Wywołano asynchroniczny interfejs API usługi internetowej (GetGizmosAsync).

GetGizmosAsync Wewnątrz treści metody wywoływana jest inna metoda GetGizmosAsync asynchroniczna. GetGizmosAsync natychmiast zwraca Task<List<Gizmo>>, które ostatecznie zostanie zrealizowane, gdy dane będą dostępne. Ponieważ nie chcesz wykonywać żadnych innych czynności, dopóki nie będziesz mieć danych gizmo, kod czeka na zadanie (przy użyciu słowa kluczowego await ). Słowa kluczowego await można używać tylko w metodach oznaczonych słowem kluczowym async.

Słowo kluczowe await nie blokuje wątku do momentu ukończenia zadania. Rejestruje pozostałą część metody jako wywołanie zwrotne dla zadania i natychmiast zwraca. Po zakończeniu oczekiwanego zadania zostanie uruchomiony mechanizm wywołania zwrotnego, co spowoduje wznowienie wykonywania metody dokładnie w miejscu, w którym zostało przerwane. Aby uzyskać więcej informacji na temat używania słów kluczowych await i async oraz przestrzeni nazw Task, zobacz async referencje.

Poniższy kod przedstawia metody GetGizmos i GetGizmosAsync.

public List<Gizmo> GetGizmos()
{
    var uri = Util.getServiceUri("Gizmos");
    using (WebClient webClient = new WebClient())
    {
        return JsonConvert.DeserializeObject<List<Gizmo>>(
            webClient.DownloadString(uri)
        );
    }
}

public async Task<List<Gizmo>> GetGizmosAsync()
{
    var uri = Util.getServiceUri("Gizmos");
    using (HttpClient httpClient = new HttpClient())
    {
        var response = await httpClient.GetAsync(uri);
        return (await response.Content.ReadAsAsync<List<Gizmo>>());
    }
}

Zmiany asynchroniczne są podobne do zmian wprowadzonych w GizmosAsync powyżej.

  • Sygnatura metody została oznaczona słowem kluczowym async, typ zwracany został zmieniony na Task<List<Gizmo>>, a do nazwy metody dołączono Async.
  • Klasa Asynchronous HttpClient jest używana zamiast klasy WebClient .
  • Słowo kluczowe await zostało zastosowane do metod asynchronicznych HttpClient .

Na poniższej ilustracji przedstawiono asynchroniczny widok gizmo.

Async

Prezentacja danych gizmos w przeglądarkach jest identyczna z widokiem utworzonym przez wywołanie synchroniczne. Jedyna różnica polega na tym, że wersja asynchroniczna może być bardziej wydajna w przypadku dużych obciążeń.

Równoległe wykonywanie wielu operacji

Metody akcji asynchronicznych mają znaczącą przewagę nad metodami synchronicznymi, gdy akcja musi wykonywać kilka niezależnych operacji. W podanym przykładzie metoda PWGsynchroniczna (w przypadku produktów, widżetów i Gizmos) wyświetla wyniki trzech wywołań usługi internetowej, aby uzyskać listę produktów, widżetów i gizmos. Projekt ASP.NET Web API, który udostępnia te usługi, używa Task.Delay do symulowania opóźnień lub wolnych połączeń sieciowych. Gdy opóźnienie jest ustawione na 500 milisekund, metoda asynchroniczna PWGasync zajmuje nieco ponad 500 milisekund do ukończenia, podczas gdy wersja synchroniczna PWG przejmuje ponad 1500 milisekund. Metoda synchroniczna PWG jest wyświetlana w poniższym kodzie.

public ActionResult PWG()
{
    ViewBag.SyncType = "Synchronous";
    var widgetService = new WidgetService();
    var prodService = new ProductService();
    var gizmoService = new GizmoService();

    var pwgVM = new ProdGizWidgetVM(
        widgetService.GetWidgets(),
        prodService.GetProducts(),
        gizmoService.GetGizmos()
       );

    return View("PWG", pwgVM);
}

Metoda asynchroniczna PWGasync jest wyświetlana w poniższym kodzie.

public async Task<ActionResult> PWGasync()
{
    ViewBag.SyncType = "Asynchronous";
    var widgetService = new WidgetService();
    var prodService = new ProductService();
    var gizmoService = new GizmoService();

    var widgetTask = widgetService.GetWidgetsAsync();
    var prodTask = prodService.GetProductsAsync();
    var gizmoTask = gizmoService.GetGizmosAsync();

    await Task.WhenAll(widgetTask, prodTask, gizmoTask);

    var pwgVM = new ProdGizWidgetVM(
       widgetTask.Result,
       prodTask.Result,
       gizmoTask.Result
       );

    return View("PWG", pwgVM);
}

Na poniższej ilustracji przedstawiono widok zwrócony z metody PWGasync .

pwgAsync

Używanie tokenu anulowania

Asynchroniczne metody akcji zwracające Task<ActionResult> są anulowalne, czyli przyjmują parametr CancellationToken, gdy jest on przekazywany z atrybutem AsyncTimeout. Poniższy kod przedstawia metodę GizmosCancelAsync z limitem czasu 150 milisekund.

[AsyncTimeout(150)]
[HandleError(ExceptionType = typeof(TimeoutException),
                                    View = "TimeoutError")]
public async Task<ActionResult> GizmosCancelAsync(
                       CancellationToken cancellationToken )
{
    ViewBag.SyncOrAsync = "Asynchronous";
    var gizmoService = new GizmoService();
    return View("Gizmos",
        await gizmoService.GetGizmosAsync(cancellationToken));
}

Poniższy kod przedstawia przeciążenie GetGizmosAsync, które przyjmuje parametr CancellationToken .

public async Task<List<Gizmo>> GetGizmosAsync(string uri,
    CancellationToken cancelToken = default(CancellationToken))
{
    using (HttpClient httpClient = new HttpClient())
    {
        var response = await httpClient.GetAsync(uri, cancelToken);
        return (await response.Content.ReadAsAsync<List<Gizmo>>());
    }
}

W podanej przykładowej aplikacji wybranie linku Demonstracja tokenu anulacji wywołuje metodę GizmosCancelAsync i demonstruje anulowanie wywołania asynchronicznego.

Konfiguracja serwera dla wywołań usług sieciowych o dużej współbieżności/dużego opóźnienia

Aby zrealizować korzyści wynikające z asynchronicznej aplikacji internetowej, może być konieczne wprowadzenie pewnych zmian w domyślnej konfiguracji serwera. Podczas konfigurowania i testowania obciążeniowego swojej asynchronicznej aplikacji internetowej należy wziąć pod uwagę.

  • Last updated on