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ę