View
424
Download
1
Category
Preview:
DESCRIPTION
Citation preview
Pomiary wydajnościŁukasz Wróbel
O mnie
…, Gadu-Gadu, Nasza-klasa, RST
Architekt
http://lukaszwrobel.pl
@lukaszwrobel
Plan
1. Po co mierzyć wydajność?
2. Jak mierzyć wydajność?
3. Czego nie robić?
4. Narzędzia
Konkretne rozwiązania różnią się w zależności od zastosowanej technologii.
Ogólne założenia pozostają niezmienne.
1. Po co mierzyć wydajność?
Żeby sprawdzić, czy spełniamy wymagania.
Można by pomyśleć, że idealnie byłoby mieć środowisko identyczne z produkcją:
● maszyny,● dane,● ruch na łączach.
Ale:● powiadomienia:
○ mail,○ komunikator.
● synchronizacja danych,● dane osobowe i biznesowe,● podwójne wdrożenia lub pełna
automatyzacja,● ...
Bardziej praktyczna jest ekstrapolacja.
Sprawdzamy w ograniczonych warunkach.
Szukamy granicy wydajności.
Oceniamy, jak to się przekłada na produkcję.
Skalowanie liniowe jest pożądane.
Według niektórych definicji, tylko takie można nazwać skalowaniem.
2. Jak mierzyć wydajność?
Od którego momentu skalowanie nie jest liniowe?
Sporządzamy wykres:● na osi X - liczba req/s● na osi Y - czas odpowiedzi
Skala na osi X musi być liniowa, inaczej interpretacja wyniku będzie nieprawidłowa.
Skalowanie nie jest liniowe, kiedy wykres przestaje być wykresem funkcji liniowej.
czasodpowiedzi
req/s
czasodpowiedzi
req/s
Odchylenie standardowe czasu odpowiedzi.
Małe odchylenie Duże odchylenie
działa stabilnie przekroczyliśmy granicę
Dobrze, żeby testy dało się łatwo powtarzać w przyszłości.
Zmiana wydajności po zmianie implementacji.
3. Czego nie robić?
“Dla kilku użytkowników działa, więc chyba nie będzie problemu”.
“Wysyłaliśmy tyle req/s i tak działało”.
Nadal nie mamy informacji, gdzie kończą się możliwości skalowania.
Trzeba wykonać testy dla różnych (rosnących) wartości obciążenia.
Produkcyjna tabela: 5mln wierszy,testowa: 10k.
Tam - dysk, tu - RAM.
Ścisłe odtwarzanie środowiska produkcyjnego jest trudne, ale nie można popadać w skrajność.
4. Narzędzia
ab
ab -n 1000 -c 50 http://example.com/test/
łącznie 1000 requestów50 równolegle
ab -n 1000 -c 50 http://example.com/
Document Length: 0 bytes
Hmm...
ab -n 1000 -c 50 http://example.com/login
Server Software: Apache/2.2.21
Server Hostname: example.com
Server Port: 80
Document Path: /login
Document Length: 12288 bytes
Concurrency Level: 50
Time taken for tests: 25.803 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 12748000 bytes
HTML transferred: 12288000 bytes
Requests per second: 38.76 [#/sec] (mean)
Time per request: 1290.133 [ms] (mean)
Time per request: 25.803 [ms] (mean, across all concurrent requests)
Transfer rate: 482.48 [Kbytes/sec] received
Requests per second: 38.76 [#/sec] (mean)
Time per request: 1290.133 [ms] (mean)
Time per request: 25.803 [ms] (mean, across all concurrent requests)
Transfer rate: 482.48 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 41 142 216.2 123 6112
Processing: 279 1098 895.0 775 4779
Waiting: 78 372 765.6 176 4282
Total: 381 1240 927.8 916 9252
Duże wahania!
Sensowny document length? Błędy?
Jeśli n małe, to możemy dostać trochę zafałszowane wyniki.Na krótką metę zadziała, ale zaraz się udusi.
Czasem warto powtórzyć testy.
Może się okazać, że zamiast znaleźć punkt, od którego wykres przestaje się skalować liniowo, zaczniemy dostawać błędy.
To też jest znak.
ab -n 300 -c 20 http://example.com/loginConnection Times (ms)
min mean[+/-sd] median max
Connect: 34 38 5.2 36 71
Processing: 64 107 24.4 106 248
Waiting: 62 106 24.5 105 248
Total: 99 145 25.1 144 283
Teraz lepiej. Patrzymy na rps.
Opcje:● dane POST/PUT,● ciasteczka,● uwierzytelnianie HTTP,● proxy.
httperf
httperf --server=example.com --uri=/login --num-conns=1000 --rate=50
Próbkowanie.
siege
Wiele adresów jednocześnie.
Narzędzia zewnętrzne.
Póki co - kosztowne w stosunku do możliwości.
Websockety
JMeter: brak dojrzałych pluginów.
Node.js lub podobne rozwiązania.
Inne narzędzia.
Zależne od kontekstu.
Nie tylko HTTP i websockety, ale też np. goła transmisja po TCP.
Dziękuję
Recommended