[a.....i]

#programowanie #python #django
Jak rzeczywiście mierzyć wydajność aplikacji webowych? Mam z tym problem bo w sumie nie wiem ile requestow na sekundę to zadowalający wynik. Przyjmijmy tylko na początek parametr taki jaki requesty. Czy np 250 req/s to spoko wynik? Wiem że istnieją takie narzędzia jak locust itd ale czy one pokażą prawdziwe wyniki? Wiadomo że w rzeczywistości wygląda to potem inaczej. Jak badacie swoje web apki pod kątem wydajności?

[croppz]

@adam_makowski: jak chcesz zobaczyć rzeczywistą wydajność to wrzuć stronę na docelowy serwer i puść testy. Loadtest, locust, obojętnie. Jeżeli chcesz po prostu porównać dwa rozwiązania to puść takie same testy na localhoście.

[Endr3w]

@adam_makowski: gatling jest spoko do tego

[a.....i]

@croppz: i to będzie w miarę miarodajne? W sumie nie wiem jaki wynik będzie zadowalający. Bo czy takie 250 req/s pozwoli zbudować coś w miarę wydajnego? Wiem że dochodzą do tego jeszcze SQL, cache itd więc ciężko to wszystko zbadać.

[croppz]

Bo czy takie 250 req/s pozwoli zbudować coś w miarę wydajnego?

@adam_makowski: na to już musisz sobie odpowiedzieć sam, bo "coś w miarę wydajnego" ma bardzo inne znaczenie w przypadku bloga i w przypadku dużego portalu aukcyjnego. Istnieją strony które pewnie nawet 10req/s nie potrzebują. ¯\_(ツ)_/¯

Jeżeli masz gotową apkę ustawioną na produkcyjnym serwerze to będzie to miarodajne, bo czemu miałoby nie być?

[a.....i]

@croppz: dziękuję za odpowiedz. Bo nie wiem czy takie testy odzwierciedlaja prawdziwy ruch i działania użytkowników?

[croppz]

@adam_makowski: to już zależy jak te testy napiszesz, puszczenie 1000x GET na stronę główną raczej nie będzie odpowiadało rzeczywistemu ruchowi na stronie. ( ͡° ͜ʖ ͡°)

[croppz]

@adam_makowski: w sumie to jeszcze jeden komentarz, bo to co wcześniej napisałem chyba zbyt pomocne nie było.

W praktyce nie ma co się specjalnie przejmować ile masz req/s, przynajmniej na etapie pisania kodu. Chyba że piszesz na przykład swoją wersję allegro albo facebooka, ale to osobna historia. ( ͡° ͜ʖ ͡°)

Jeżeli w praktyce okaże się że któryś endpoint jest za wolny to wtedy się bierzesz

[L.....k]

Nie da się stwierdzić czy 250req/s to dobry wynik nie znając wielkości serwera, czy metod których użyłeś.
Stronę ostatecznie i tak schowasz za CDNem który przyjmie na siebie 95% obciążenia

[b.....u]

@adam_makowski: To zależy :) Po co chcesz robić te testy?

wysyłanie 250 requestów na sekundę to nie jest żaden parametr testówy wydajnościowych, tylko obciążenie które generujesz :) Mierzyć trzeba odpowiedzi na te 250 requestów. Jeżeli odpowiedź na 200 request będzie trwała 15 sekund, to na pewno jest źle. Jeżeli odpowiedź z serwera będzie trwać 1,5 sekundy to może być albo bardzo dobrze, albo przeciętnie, albo tragicznie :)

Normalnie badania wydajnościowe wyglądają tak:
- tworzymy środowisko które jest idealną

[b.....u]

@adam_makowski: tl;dr - nie ma sensu testować wydajności lokalnie ani na środowiskach dev/test, nie ma też sensu wykonywać testów otwierania strony głównej dla 250 userów, bo wtedy testujesz nie kod aplikacji tylko serwer apacha, nginxa czy gunicorna (albo czegokolwiek innego czego używasz do serwowania apki)

[a.....i]

@buntuubuntu: o dziekuje, takiej odpowiedzi oczekiwalem.
Teraz na szybko stworzylem srodowisko do produkcji, droplet na digitalocean cpu optimized 4 cpu 8gb.
Docker, Django, Nginx, Gunicorn [Uvicorn], Redis, PostgreSQL
Pusciłem loadtest na 15k requestow z iloscia 500 userów. Wynik jaki otrzymałem to widoczny na screenie.
Rozumiem to ze jest to tak na prawde tylko test na nginx, gunicornie i redisie bo zostaja najwazniejsze SQL i na to potrzeba dodatkowych testow.
Co ciekawe jak puscilem ten test i na przegladarce probowalem ogladac strone to widoki cachowanie przez redisa smigaly az milo a inne widoki juz nie cachowane mulily do kilku sekund. Ale time out nie wyrzucalo wiec jakis

[L.....k]

@adam_makowski: Przeczytaj jakikolwiek artykuł o profilowaniu aplikacji bo chałupniczo to kolejne dwa lata będziesz wszystko odkrywał...

- Pliki statyczne na CDN to podstawa
- Stronę profilujesz bez cacheowania na redisie, na czystej aplikacji, inaczej będziesz sprawdzał wydajność redisa. Poza tym powinieneś cacheować warstwę wyżej, np na poziomie CDNa z wykorzystaniem eTagów.
- Na screenie który wrzuciłeś masz strasznie wysokie czasy odpowiedzi, średnio 3.6s? Kto będzie tyle czekał? Znajdź w googlu jak czas odpowiedzi wpływa na ilość odwiedzających na stronie i celuj mniej więcej w tę wartość. Taki wynik powinieneś mieć dla 95-99 percentyla, w tym momencie 10% użytkowników twojej strony czeka na załadowanie 7 sekund lub dłużej. Z tego co pamiętam optymalnie jest ok 2.5 sekundy.
- Zapytania do bazy danych testujesz lokalnie, głównie szukasz n+1 problem, ewentualnie czy nie pobierasz za dużo danych

[a.....i]

@buntuubuntu: @Lunatik: poprawilem wlasnie wyniki, jest duza roznica. Przenioslem wszystko na S3. Oto wyniki.
Testowalem bez redisa, z redisem sa mniejsze wyniki.... Dziwne
Gunicorna uzywam wedlug zalecen 2x2+1.
dziekuje wszystkim za odpowiedzi i wskazowki

[L.....k]

@adam_makowski: Nie ma uniwersalnych zaleceń dla gunicorna. Trzeba profilować i dobrać pod siebie.

S3 nie nadaje się do serwowania plików dla użytkowników końcowych przez duże opóźnienia, dorzuć do tego Amazon Cloudfront i będziesz pan zadowolony

[a.....i]

@Lunatik: badałem temat cloudfronta i będę testował także. Tak czy siak ciągle jestem w testach ( ͡° ͜ʖ ͡°)co ciekawe najpierw dbam o wydajność a kod prawie stoi w miejscu. Chyba robię na odwrót no ale co ja poradzę że optymalizacja przynosi mi satysfakcję ( ͡° ͜ʖ ͡°)

[b.....u]

@Lunatik: a potem zmienisz kod i trzeba będzie przerabiać polowe optymalizacji, zła kolejność, chyba ze Ci się nie spieszy i się uczysz