ASP.NET - kod asynchroniczny a responsywność aplikacji

Question

Cześć wszystkim, ostatnio piszę aplikacje w asp.net (mvc nie core) i mam refleksje na temat programowania asynchronicznego w pisaniu witryn internetowych w asp.net. Wiem, że kod asynchroniczny sprawia, że aplikacja jest bardziej responsywna. Poprzez mówienie, że aplikacja jest "responsywna" mam na myśli, że jeśli mamy przykładowo akcję kontrolera, która jest asynchroniczna i wewnątrz tej akcji jest jakaś metoda, która wykonuje się asynchroniczne (z użyciem słówka await) to gdy wykonywana jest ta metoda to w międzyczasie wątek główny może wykonywać inne zadania (np: obsługiwać interfejs do komunikacji z użytkownikiem). Dzięki temu aplikacja jest cały czas do dyspozycji. Moje pytanie brzmi: skoro tak jest to czy należy każdą akcję każdego kontrolera uczynić metodami asynchronicznymi? Szczerze wydaje mi się, że odpowiedź na to pytanie powinna być "nie", bo czytałem kiedyś, że aplikacje asp.net są uruchamiane za pomocą IIS, który ma swoją pulę wątków i właśnie IIS dba o to, aby aplikacja była w stanie zawsze obsłużyć w danym momencie wszystkie żądania (każde żądanie otrzymuje jeden wątek z puli). Nie jestem pewien tego co wiem obecnie i szukałem odpowiedzi w google'u, ale nie udało mi się cokolwiek znaleźć, więc chcę tutaj uzyskać odpowiedź. Czy programowanie asynchroniczne jest konieczne, aby aplikacja była w stanie obsłużyć w jednym momencie wszystkie żądania czy może zajmuje się tym IIS i programowanie asynchroniczne nie ma tutaj zastosowania? Kiedy używać async metod i await w aplikacjach asp.net?   

Answer 1

W aplikacjach ASP .NET, asynchroniczności powinieneś używać odwołując się do zewnętrznych zasobów (np. do bazy danych).

Mając obsługę zapytań synchronicznych, masz ograniczoną pulę wątków, gdy wszystkie zostaną zajęte zapytanie musi czekać w kolejce

Wykorzystując asynchroniczność, obsługa zapytania zwraca wątek do puli kiedy czeka na zakończenie wywołania zewnętrznego zasobu dzięki czemu ten wątek w międzyczasie może zająć się kolejnym zapytaniem.

Dogłębniej zostało to opisane w tym artukule (jest to również źródło obrazków):

https://docs.microsoft.com/en-us/archive/msdn-magazine/2014/october/async-programming-introduction-to-async-await-on-asp-net

A tutaj ogólny opis zasady działania asynchroniczności:

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/

Comments

Dzięki wielkie, w końcu znalazł się ktoś kto się zna! (to nie jest ironia) Czyli moje domysły były dobre. Kod asynchroniczny może pomóc w uniknięciu blokowania się aplikacji, ale to pewnie ma zastosowanie tylko u witryn, które mają duży ruch sieciowy a w małych aplikacjach pewnie nie. 

PS.

Swoją drogą jak to jest z bazami danych, które są obsługiwane przez Entity Framework, bo wiem, że obiekty DbSet<T> reprezentują tabele z bazy danych i jeśli coś wykonujemy na tych kolekcjach DbSet to musimy używać tych asynchronicznych metod, które oferuje ta kolekcja takich jak FindAsync? Czy po prostu używać asynchronizacji przy wywołaniu SaveChanges[Async]? No bo jeśli te metody robią coś z bazą danych to pewnie się odwołują do zewnętrzengo zasobu jakim jest właśnie baza danych i może lepiej jest użyć tych async metod, aby zapobiec blokowaniu aplikacji?

Jeszcze raz dzięki za odpowiedź!

---

Entity Framwork udostępnia metody z końcówką async właśnie w celu uniknięcia blokowania wątku na czas oczekiwania na zakończenia operacji w bazie danych.

Dla przybliżenia tematu możesz przeglądnąć:

• https://docs.microsoft.com/en-us/ef/core/miscellaneous/async
• https://stackoverflow.com/questions/40563046/should-all-entity-framework-methods-use-async

---

Aha czyli niektóre z tych metod wykonują jakieś operacje z bazą i dlatego mają swoje asynchroniczne odpowiedniki. Dzięki wielkie!

Answer 2

Pomyliłeś zagadnienia 

kod asynchroniczny sprawia, że aplikacja jest bardziej responsywna. 

Responsywna może być strona : co oznacza, że dostosowuje się do skalowania i różnych urządzeń, tutaj asynchroniczność nie ma nic do rzeczy, asynchroniczność pozwala Ci na wykonywanie aplikacji współbieżnie. 

Nie powoduje to, że aplikacja jest bardziej responsywna, ale zniechęca do blokowania wątków, co jest częstą przyczyną niereagujących aplikacji.

Comments

Dobrze, faktycznie zniechęca do blokowania wątków, ale jak się odniesiesz do całości tego co napisałem wyżej?

---

jeżeli twój kontroler wymaga asynchroniczności, to znaczy że  źle napisałeś API :) i coś robisz nie tak, Controler ma obsłużyć żądanie i zwrócić odpowiedź z serwera, 1 zasób -> to 1 kontroler więc tutaj obsługa jest zawsze jednego endpointu przez dany kontroler.

Pytanie po co Ci potrzebna "api" do dyspozycji, co chcesz robić niby podczas obsługi żądania innego ? 
Zrozum jedno 1 użytkownik -> 1 żądanie w danym momencie, więc nie potrzebujesz obsługi WIELU ŻĄDAŃ  na raz, natomiast każy użytkownik ma indywidalny w ramach swojej sesji zasób, wątek przydzielony do obsługi, toteż nigdy nie słyszałem aby asynchroniczności wymagał kontroler. 

Chociaż w myśl definicji 

Kontroler asynchroniczny umożliwia pisanie metod akcji asynchronicznych. Umożliwia wykonywanie długotrwałych operacji bez powodowania bezczynności działającego wątku. Nie oznacza to, że wykonanie akcji zajmie mniej czasu. Jeśli żądanie tworzy wywołanie usługi, które wymaga dwóch sekund na jego ukończenie, żądanie potrwa dwie sekundy, niezależnie od tego, czy jest wykonywane synchronicznie, czy asynchronicznie. Jednak podczas wywołania asynchronicznego serwer nie jest blokowany w odpowiedzi na inne żądania.

Asynchroniczne metody akcji są przydatne, gdy akcja musi wykonać kilka niezależnych długotrwałych operacji. Załóżmy, że mamy trzy operacje, które trwają 500, 600 i 700 milisekund. W przypadku wywołania synchronicznego całkowity czas odpowiedzi wynosiłby nieco ponad 1800 milisekund. Jeśli jednak wywołania są wykonywane asynchronicznie (równolegle), całkowity czas odpowiedzi będzie nieco dłuższy niż 700 milisekund, ponieważ jest to czas trwania najdłuższego zadania/operacji.

I generalnie tutaj w ASP to serwer odpowiadałby za asynchroniczność implementując interefejs 

AsyncController

 z pakietu MVC, ale generalnie nie widze takiej potrzeby przy realizacji małych programów, czy własnych rozwiązań monolitów, co innego jeśli tworzysz mikroserwis 

---

jeżeli twój kontroler wymaga asynchroniczności, to znaczy że  źle napisałeś API :) i coś robisz nie tak, Controler ma obsłużyć żądanie i zwrócić odpowiedź z serwera, 1 zasób -> to 1 kontroler więc tutaj obsługa jest zawsze jednego endpointu przez dany kontroler.

Raczej kontrolery mogą być async w szczególności gdy są sytuacje gdzie potrzeba wykonać asynchronicznie jakieś zadanie. Gdy przeglądałem internet wielokrotnie widziałem, że ludzie pisali, że gdy są operacje I\O zawsze powinniśmy używać async metod albo async akcji. Zwykle jako przykład takiej operacji ludzie podawali połączenie z bazą danych lub czekanie na wynik z bazy danych albo odczytywanie plików. Poza tym pewien pan zrobił na yt kurs z asp.net core i on używa dosyć często asynchronicznych akcji w pewnym projekcie: https://github.com/mariuszjurczenko/PortalRandkowy (zauważ tutaj, że każde operacje związane z repozytorium, która jest związana z bazą danych to każda taka operacja jest wykonywana asynchronicznie)

Kiedyś pamiętam, że uczestniczyłem w pewnym projekcie open source, gdzie były też kontrolery (choć żeby być dokładnym powiem, że tamte kontrolery obsługiwały komendy bota discordowego a nie żądania użytkowników) i tamte kontrolery praktycznie wszystkie w całości były asynchroniczne (link do repo: https://github.com/Devscord-Team/Watchman).

Zrozum jedno 1 użytkownik -> 1 żądanie w danym momencie, więc nie potrzebujesz obsługi WIELU ŻĄDAŃ  na raz, natomiast każy użytkownik ma indywidalny w ramach swojej sesji zasób, wątek przydzielony do obsługi, toteż nigdy nie słyszałem aby asynchroniczności wymagał kontroler.

Źle mnie rozumiesz. Mi nie chodzi o to, że jeden użytkownik musi wyemitować kilka żądań jednocześnie, ale że aplikacja musi obsłużyć jednocześnie kilka żądań, które mogą pochodzić na przykład od wielu użytkowników. Na przykład Facebook w ciągu jednej chwili ma wiele żądań od użytkowników z różnych stron świata i musi to wszystko obsłużyć. Nie możemy wykonywać tylko jednego żądania jeśli jest kilka żądań teraz (tak wiem mogą być sytuacje gdzie żądań będzie zbyt i dojdzie do kolejkowania żądań, ale ja chcę tylko wiedzieć jak zrobić, aby aplikacja obsługiwała wiele żądań, choć kto wie może nie trzeba nic robić, może ten IIS wszystko zrobi, właśnie dlatego zadałem tutaj pytanie, aby się dowiedzieć)

PS.

Dodatkowo dodam, że jeśli chodzi o twój przykład z operacjami, które wykonują się ileś milisekund to wiem, że istnieje taka możliwość używania kodu asynchronicznego w taki sposób, tylko, że to jest bardziej zrobione z perspektywy programowania równoległego/współbieżnego a mi chodzi o wykorzystanie klasycznej asynchronizacji w asp.net (klasycznej w sensie, że jeden wątek/zadanie wykonuje poboczną operacje, zaś główny wątek/zadanie wykonuje inne zadania).

I jeszcze jedno jako ciekawostka - kiedyś AsyncController był wymagany w asp.net dla asynchronicznych kontrolerów, teraz nie ma takiej konieczności.