[maestrozo]

Mam pytanie dotyczące web api w Asp.Net Core.
Czy jeśli endpointy nie są ustawione jako async to znaczy, że tylko jedno żądanie może być obsługiwane w tym samym czasie?

#programowanie #netcore #dotnet #webdev

[ghostface]

@maestrozo: nie, wiele żądań będzie obsługiwanych na raz, Kestrel jest wielowątkowy.

[maestrozo]

@ghostface: dobrze rozumiem, że przydzielania jest dynamiczna liczba wątków w zależności od liczby żądań?

[Passer93]

@maestrozo: To jest ASP.NET Core, tutaj nie powinienes myśleć w kategori wątków bo to jest abstracted away xD
Chcesz żeby serwer się skalował na dużą liczbe połączen to robisz async, chcesz żeby latency na pojedynczego requesta było jak najmniejsze to nie używasz asynca.

Async daje tylko jedna rzecz, jeśli na tasku będzie wywolany await a task nie ma cpu-bound pracy do wykonania tylko np jakieś operacje sieciowe, to wątek który

[M.....v]

@maestrozo: Asynchroniczność != wielowątkowość. Asynchroniczność polega na tym, że wątek jest zwalniany w momencie, kiedy wykonuje się operacja I/O (odczyt z dysku, zapis/ odczyt z bazy danych, komunikacja sieciowa).

Przykładowe zapytanie wygląda mniej więcej tak w większości przypadków:
- Przetwarzanie requestu 5ms
- odczyt czegoś z bazy danych 100ms
- przetworzenie odpowiedzi z bazy

[maestrozo]

@Maav @Passer93 czyli tak naprawdę asynchroniczność będzie pomocna jeśli serwer będzie miał duże obciążenie, czyli w praktyce jeśli wszystkie wątki odpowiedzialne za przetwarzanie żądań będą w użyciu?

[Passer93]

@maestrozo: asynchronicznisx jest pomocna tylko wtedy gdy to co robisz w tasku nie jest cpu-bound, czyli jakieś operacje i/o na plikach, połączenie do bazy itp.
Wtedy dajesz możliwość runtime na przełączanie się, ale to koniec końców od niego wszystko zależy.

Pytanie który musisz sobie zadać to czy co robisz w środku taska jest cpu-bound czy nie. Jeśli jest to nic nie zyskasz przez asynca a nawet stracisz przez narzut.

[M.....v]

@maestrozo: Jak @Passer93 napisał wyżej, jeśli chcesz osiągnąć większą ilość request/s, to asynchroniczność jest super.
Im więcej zrzucasz na bazę danych/ komunikację z inną aplikacją itp, i im dłużej to trwa, tym bardziej asynchroniczność pomaga.

Jeśli wykonujesz krótkie zapytania (powiedzmy, że <50-60ms. Oczywiście to zależy od konkretnego serwera, jego szybkości itp. Warto wykonać testy wydajności, żeby wiedzieć), to możliwe, że to się nie opłaca, bo zmiana kontekstu będzie trwać

[maestrozo]

@Maav @Passer93 aha chyba rozumiem. Moja aplikacja to sklep internetowy. Jak na razie mam w niej same CRUDY. Są to raczej szybkie operacje to myślę że nie ma co zmieniać akcji na asynchroniczne.

[elbombero]

Tylko kolejne rzeczy I/O rób już async. To jest standard teraz. Narzut minimalny.