Czy jest możliwe zwiększenie zasobów w puli aplikacji na serwerze?
Jeżeli jest mozliwe to jak to jak to zrobić?
0
0
Klikasz PPM na puli i wybierasz Advanced Settings. A co konkretnie chcesz zmienić?
0
somekind napisał(a):
Klikasz PPM na puli i wybierasz
Advanced Settings. A co konkretnie chcesz zmienić?
Chciałem przydzielić wiecej zasobów, bo wydaje mi się, że przez to przepustowość serwera jest słabsza, albo po prostu coś blokuje mi aplikacje na serwerze.
0
Ale jakich zasobów? Domyślnie zarówno procesor jak i pamięć są nielimitowane.
0
Błąd w odpowiedziach na requesty mi wychodzi ponad 80 procent. Ktoś mi powiedział, że spowodowane to jest tym, ze wyczerpuje się pula wątków na serwerze + zapełnia backlog socketu i wtedy wszystkie requesty kończą się momentalnie czymś typu "Connection refused". Dlatego pomyślałem, by jakoś zwiększyć zasoby, bo już nie mam pomysłu dlaczego aż tyle błędów jest. (windows IIS)
Całkiem podobny przypadek ale teraz w przepustowością: gdize na kestrelu mam przepustowość na sekundę 350/s, natomiast w full iis 1000/s, co zdecydowanie wydaje mi się zle, bo kestrel raczej powinien być szybszy (w obu przypadku aplikacja korzysta z out of process hostingu)
2
Domyślny limit wątków w ThreadPool przetwarzających requesty wynosi 32 tysiące, limit wątków obsługujących I/O to 1 tysiąc (na windowsie, na linuksie nie ma podziału). Każdy wątek zajmuje +/- 1 MB, więc żeby uderzyć w te limity potrzebujesz z grubsza z 34 GB RAMu, czyli bardziej prawdopodobne by było że zabraknie ramu niż uderzysz w te limity. Na dodatek użycie asyn/await znacznie zmniejszą użycie wątków z ThreadPool, przez ich współdzielenie przez requesty w trakcie asynchronicznego I/O.
to co może być problemem, to że aplikacja domyślnie startuje z liczbą wątków w puli równą liczbie rdzeni procesora, tworzenie nowych wątków trochę zajmuje, więc jak od razu zaatakujesz aplikację niespodziewanie dużym ruchem to początkowa przepustowość może ucierpieć, liczbę wątków w puli podnosi się za pomocą:
public static bool ThreadPool.SetMinThreads (int workerThreads, int completionPortThreads);
Ale to jest czyste zgadywanie, po raz kolejny powtarzam że tylko zebranie metryk może dać odpowiedź gdzie jest wąskie gardło.
0
Wyslałem niby 10k requestow na sekundę i dostałem taki graf w metryce od programu JMeter. Niby 10k na sekundę a pokazuję zużycie procesora przez 10 sec na full dla 100 użytkowników? Czyli wąskim gardłem w moim przypadku okazał się procesor, czy jak mam to interpretować?
2
Tak ,wąskim gardłem jest procesor, teraz przydałoby się to zużycie CPU rozbić na poszczególne procesy, bo może się okazać że jak odpalasz JMeter na tym samym komputerze to on zjada większość CPU. Jeśli jednak większość zużywa nasz aplikacja to idziemy dalej, sprawdzamy metryki dotyczące GC, błędów, i locków naszej aplikacji, jak wszystko wygląda dobrze to pozostało nam profilowanie aplikacji i znalezienie gorących ścieżek które najbardziej obciążają procesor ich optymalizacja.