Witam, zaczynam przygodę z ASP.NET MVC 5 i nie bardzo rozumiem dlaczego należy stosować async i await w metodach akcji kontrolera. Jak mógłby mi ktoś przybliżyć ich zastosowanie i wyjaśnić czym będzie się różnić od zwykłej metody nie posiadającej async/awaitk, byłbym wdzięczny.
Pozdrawiam
1
C# 
- Rejestracja:około 17 lat
- Ostatnio:około godziny
- Lokalizacja:Wrocław
4
Wielki Orzeł napisał(a):
Witam, zaczynam przygodę z ASP.NET MVC 5 i nie bardzo rozumiem dlaczego należy stosować async i await w metodach akcji kontrolera. Jak mógłby mi ktoś przybliżyć ich zastosowanie i wyjaśnić czym będzie się różnić od zwykłej metody nie posiadającej async/awaitk, byłbym wdzięczny.
Pozdrawiam
W dużym uproszczeniu - dzięki temu metoda nie "blokuje" procesora, więc można ich wykonywać więcej "na raz". Ma to sens przy wielu żądaniach do aplikacji, wówczas gdy akcje kontrolera czekają na coś niezależnego od procesora, czyli np. operacje dyskowe, odczyt z bazy danych, itp.
Zamiast pisać w cudzysłowach możesz napisać o wątkach i np napisać, że jest tylko jeden wątek dla kontrolera (tak wnioskuję z wypowiedzi), a async przerzuca zawarte w nim zadanie na oddzielną pulę wątków, zamiast blokować wątek kontrolera.
- Rejestracja:ponad 22 lata
- Ostatnio:8 dni
0
Pociągnijmy jeszcze temat. Akcje kontrolerów są wykonywane wielowątkowo (na ilu wątkach zależy od konfiguracji IIS). Przeglądarka i tak czeka na otrzymanie całej strony (w sensie html), a nawet jeśli nie, to response jest wysyłany po zakończeniu akcji, a nie w jej trakcie. Z kolei czekanie na plik czy bazę danych jest asynchroniczne, czyli wątek idzie spać aż sterownik odpowie danymi.
Jaki jest więc zysk z asynchronicznego wykonania kodu kontrolera?
[edit]
Taką odpowiedź znalazłem, ale nie przekonuje mnie:
tech.pro/q/12/async-vs-sync-aspnet-mvc napisał(a)
"if they have seen a significant increase in performance?"
I'm not so sure this is the right question... Using the async/await syntax in most cases would not increase the response time of your website in a significant way... Technically, for a low-load ASP.net instance, it will probably introduce a bit of overhead (although probably unnoticeable).
The main benefit that the async/await keywords will provide is an increased "scalability factor". The async keyworkd could be used in conjunction with any blocking IO operations that are done server side, which before-hand would have held up that thread, which is part of the IIS Application Pool.
Since the Application Pool has a limited number of threads available to it, in high-load web applications, using async/await for all of the IO operations will essentially "grease the pipes" of IIS, and make sure that those threads are always being "productive".
Blocking IO wykonywane asynchronicznie nadal potrzebuje wątku, który będzie spał czekając na zakończenie operacji, niezależnie od tego, czy to będzie wątek puli IIS, czy wątek od async'a.
edytowany 4x, ostatnio: ŁF
Zobacz pozostały 1 komentarz
A jednak taka metoda jest proponowana i ogólnie w internecie, i jako odpowiedź w tym zadaniu.
Przy większych aplikacjach róznica jest zdecydowanie zauważalna
Dlaczego?
https://robinsedlaczek.wordpress.com/2014/05/20/improve-server-performance-with-asynchronous-webapi/, IIS ma ograniczoną pulę wątków, jak wynika z artykułu, wątki dzielą się na workery i completion port (I/O). W przypadku synchronicznych kontrolerów, z tego co rozumiem w przypadku operacji I/O, blokowany jest zarówno worker jak i completion port. W przypadku asynchronicznych, worker może być w tym czasie użyty do obsługi innych żądań.
Tutaj też ciekawy opis https://msdn.microsoft.com/en-us/magazine/dn802603.aspx
- Rejestracja:około 17 lat
- Ostatnio:około godziny
- Lokalizacja:Wrocław
2
ŁF napisał(a):
Akcje kontrolerów są wykonywane wielowątkowo (na ilu wątkach zależy od konfiguracji IIS). Przeglądarka i tak czeka na otrzymanie całej strony (w sensie html), a nawet jeśli nie, to response jest wysyłany po zakończeniu akcji, a nie w jej trakcie. Z kolei czekanie na plik czy bazę danych jest asynchroniczne, czyli wątek idzie spać aż sterownik odpowie danymi.
Synchroniczna akcja kontrolera jest wykonywana w jednym wątku, czekanie na plik czy bazę jest... po prostu czekaniem. Wątek wtedy nic nie robi, ale jest zajęty i niedostępny dla kolejnych żądań.
Blocking IO wykonywane asynchronicznie nadal potrzebuje wątku, który będzie spał czekając na zakończenie operacji, niezależnie od tego, czy to będzie wątek puli IIS, czy wątek od async'a.
Wątki IIS służą do obsługi żądań. Przy odpowiednio dużej liczbie żądań, i odpowiednio długich czasach odpowiedzi spowodowanej czekaniem na zewnętrzne zasoby, IIS może nie być w stanie odpowiadać na kolejne żądania, mimo względnie niskiego zużycia procesora. Asynchroniczne kontrolery rozwiązują ten problem - wątki nie są blokowane, więc czekając na odpowiedź I/O mogą obsługiwać kolejne żądania.
Nie zapominajmy też, że każdy wątek zajmuje pamięć. Mniej wątków IIS, to mniej zajętej pamięci.
niezdecydowany