Narzędzia do pomiarów wydajności strony

N

Wydajność to pieniądze. Dużo pieniędzy. Trainline zredukowało czas ładowania strony o 0,3 sekundy. Efekt? Klienci zostawili w sklepie 8 milionów funtów więcej w skali roku[1].  Netflix, włączając kompresję gzip, zaoszczędził 43% na ruchu wychodzącym[2]. Oszczędność liczona w milionach dolarów. Przykłady można mnożyć w nieskończoność…

Ale jak to mierzyć? Skąd mamy wiedzieć jak szybko ładują się nasze strony? To, że u nas na komputerze strona ładuje się w 2 sekundy, nie oznacza, że u sąsiada obok strona wczyta się równie szybko. Na czas ładowania aplikacji składają się 4 rzeczy: wydajność serwera, optymalnie napisany kod, wydajność komputera/smartfona użytkownika oraz internet, z którego użytkownik łączy się z nasza stroną. Nawet jeśli serwer odpowie nam w ciągu pół sekundy, mając źle zoptymalizowany kod, użytkownik zobaczy stronę po paru-parunastu sekundach, jeśli ma wolny komputer, strona może ładować się nawet minutę. Optymalizacja to temat rzeka, zostawię go na osobny wpis.

Poniżej przedstawiam narzędzia, których używam na codzień do monitorowania wydajności tworzonych przeze mnie aplikacji.

Narzędzia do pomiaru wydajności serwera

#1 Loader.io

Moje ulubione narzędzie do mierzenia wydajności serwera. Jedną z zalet tej usługi jest możliwość testowania kilku podstron na raz. Co najważniejsze, narzędzie jest darmowe. W podstawowym pakiecie możemy dodać 1 domenę, każdy test może trwać maksymalnie minutę i jednocześnie możemy testować 2 urle.

Wersja płatna kosztuje 100 dolców miesięcznie, co dla większych firm raczej nie będzie wielkim wydatkiem, biorąc pod uwagę możliwości jakie daje nam to narzędzie. Nielimitowana ilość domen, testy trwające maksymalnie 10 minut oraz 10 urli do jednoczesnego testowania w zupełności wystarczy by w pełni sprawdzić zachowanie serwisu pod obciążeniem.

Narzędzie oferuje nam 3 rodzaje testów:

  • użytkownicy na test – jeśli ustawimy 20000 użytkowników na 20 sekund, oznaczać to będzie, że na naszą stronę wejdzie w ciągu sekundy 1000 userów.
  • użytkownicy na sekundę – test podobny do powyższego, różni się tym, że na start podajemy, iż chcemy mieć 1000 userów na sekundę.
  • utrzymywanie obciążenia – utrzymuje x użytkowników przez cały czas trwania testu.

Więcej o specyfice testów na stronie loader.io.

Wykonałem te testy dla swojego bloga, efekty wraz z krótkim komentarzem poniżej.

Użytkownicy na test
1.1 Użytkownicy na test

W początkowej fazie testu, wyraźnie widać, że cache dopiero się rozgrzewał. Dzięki temu, późniejsze zapytania nie musiały być generowane na nowo, blog serwował statyczny, raz wygenerowany dokument. Czas odpowiedzi na poziomie 138 ms to wzorowy wynik.

 

Użytkownicy na sekundę
1.2 Użytkownicy na sekundę

Test, którego obawiałem się najbardziej. 1000 użytkowników na sekundę to bardzo dużo. Serwer odpowiadał średnio w 3,8 sekundy. Niejeden serwis z tylko jednym użytkownikiem na stronie odpowiada w takim czasie. Po takim teście wiem, że mogę być spokojny w przypadku viralowego wpisu. Strona spokojnie utrzyma obciążenie.

 

Utrzymywanie obciążenia
1.3 Utrzymywanie obciążenia

Ten test, pokaże nam jak się zachowa serwer w przypadku rosnącego w popularność materiału na naszej stronie – ktoś wrzuca link np. na facebooka i w ciągu minuty napływa nam 14500 użytkowników. Tak jak w przypadku pierwszego testu, na początku cache się rozgrzewa, stąd ten pik w górę. Następne żądania strony są serwowane z raz wygenerowanego dokumentu dzięki czemu uzyskujemy średni czas odpowiedzi na poziomie 518 ms.

#2 Pingdom

Nikt nie lubi dowiadywać się, że jego strona nie działa od klientów. Awarii serwera przewidzieć się nie da. Da się za to monitorować down time. Drugie narzędzie, którego używam pinguje z wielu miejsc na świecie(głównie USA stąd czasy ~1 sekundy), czy nasz serwer jest online. Pingdom jest darmowy, oferuje podstawowe monitorowanie down time wraz z możliwością ustawienia maili z informacją o tym, że serwer leży.

W wersji płatnej, dostajemy powiadomienia sms, monitorowanie wielu domen, monitorowanie wydajności frontu… O wszystkich możliwościach usługi, możesz poczytać na stronie Pingdom.com.

2.1 Dashboard narzędzia Pingdom

Jak widać na powyższym raporcie. Przez ostatnie 30 dni, mój blog padł 18 razy. Łącznie niedostępny był przez 2 godziny, co w skali miesiąca daje uptime na poziomie 99,7%. Skąd ten down time? Blog ruszył niedawno, konfiguracja szybkiego środowiska produkcyjnego wymagała kilkunastu restartów maszyny i podnoszenia na nowo usług. Gdybym nie wykonywał prac na serwerze i świadomie go nie wyłączał, Pingdom daje możliwość sprawdzenia z dokładnością co do minuty kiedy serwer był offline co ułatwi nam poszukiwanie winowajcy.

#3 ApacheBench

AB jest bardzo prostym narzędziem CLI dostarczanym wraz z serwerem Apache. Służy do testowania wydajności serwera HTTP. ApacheBench odpalamy na swoim komputerze z poziomu terminala. Przykład użycia:

ab -n 100 -c 100 https://devbay.pl/
 This is ApacheBench, Version 2.3 <$Revision: 1757674 $>
 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
 Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking devbay.pl (be patient).....done
 Server Software: nginx
 Server Hostname: devbay.pl
 Server Port: 443
 SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
 TLS Server Name: devbay.pl

Document Path: /
 Document Length: 19427 bytes

Concurrency Level: 100
 Time taken for tests: 5.316 seconds
 Complete requests: 100
 Failed requests: 0
 Total transferred: 2004900 bytes
 HTML transferred: 1942700 bytes
 Requests per second: 18.81 [#/sec] (mean)
 Time per request: 5316.144 [ms] (mean)
 Time per request: 53.161 [ms] (mean, across all concurrent requests)
 Transfer rate: 368.30 [Kbytes/sec] received

Connection Times (ms)
  min mean[+/-sd] median max
 Connect: 781 1067 254.9 951 1455
 Processing: 2987 3213 154.3 3182 4348
 Waiting: 2968 3186 102.2 3174 3347
 Total: 3934 4281 228.4 4300 5301

Percentage of the requests served within a certain time (ms)
  50% 4300
  66% 4344
  75% 4422
  80% 4518
  90% 4557
  95% 4561
  98% 4577
  99% 5301
  100% 5301 (longest request)

Wyniki w dużej mierze zależą od łącza internetowego, z którego testujemy. Ja wykonałem test z internetu mobilnego. Te testy najlepiej jest wykonywać na localhoście w momencie kiedy jeszcze produkujemy stronę. Z powyższego wyniku interesuje nas najbardziej Requests per second i czasy połączenia.

Narzędzia do mierzenia wydajności frontu

#1 SpeedCurve

O SpeedCurve dowiedziałem się na tegorocznej konferencji InfoShare w Gdańsku. Od tamtego czasu nieustannie korzystam z dobrodziejstw tej usługi zarówno przy monitorowaniu jak i samym procesie optymalizacji aplikacji. Narzędzie jest płatne, oferuje model „zapłać za to, co zużyjesz”. Wykonanie jednego testu kosztuje 0.01 dolara. Próg płatności wynosi 20 dolarów miesięcznie, co średnio daje nam  66 testów na dzień. Największą zaletą tego narzędzia jest możliwość testowania z wielu miejsc na świecie, z wielu urządzeń – zarówno mobilnych jak i desktopowych.www

Funkcjonalności z których korzystam:

  • wyświetlanie czasu renderowania(rozpoczęcia, prędkości, wizualnie gotowej strony), animacja poklatkowa pokazująca proces renderowania strony, czas ładowania strony(wysłanie pierwszego bajta z serwera, rozpoczęcie ładowania i zakończenie), ilość plików blokujących renderowanie(css + js), wielkość assetów(css, js, obrazy, fonty, flash, etc)
  • deploy – możemy zrobić test przed i po wdrożeniu a następnie porównać wyniki
  • responsywność – testuje wszystko z punktu pierwszego na kilku urządzeniach mobilnych i desktopowych
  • monitorowanie użytkowników w czasie rzeczywistym – pełny opis dostępny tutaj
SpeedCurve rendering
1.1 Czasy renderowania strony
SpeedCurve deploy
1.2 Deploy – przed i po wdrożeniu
SpeedCurve pageload
1.3 Responsywność

Zachęcam do przetestowania, SpeedCurve daje ogrom możliwości. Pierwszy miesiąc jest za darmo – https://speedcurve.com/plan/trial/

#2 GTMetrix

Narzędzie, które korzysta z algorytmów PageSpeed oraz YSlow opartych o zasady Steve’a Soudersa. Narzędzie jest darmowe, w podstawowej wersji oferuje nam mierzenie wydajności frontu z serwerów Kanadyjskich przez co czasy mogą być nieco większe. Zadaniem GTMetrix’a jest ocenienie naszej aplikacji oraz ewentualne wskazówki co możemy poprawić. Stosując się do tych wytycznych jesteśmy w stanie poprawić wydajność nawet o 50%. Na algorytmy PageSpeed i YSlow poświęcę osobny artykuł.

Raport, który wypluwa GTMetrix wygląda następująco:

GTMetrix
2.1 Raport GTMetrix

Poniżej tego mamy wytyczne, którymi powinniśmy się kierować. Na zrzucie się nie mieści, cały raport możecie zobaczyć tutaj.

#3 Google PageSpeed Insights

Narzędzie w pełni darmowe, analogiczne do GTMetrixa. Dodatkowo daje nam możliwość oceny wydajności dla urządzeń mobilnych.

Google PageSpeed Insights

1 https://www.youtube.com/watch?v=ai-6qwT6ES8
2 http://cdn.oreillystatic.com/en/assets/1/event/7/Improving%20Netflix%20Performance%20Presentation.pdf

 

O autorze

Filip Nowacki

Swoją przygodę z IT rozpoczął mając 13 lat, kiedy to stworzył swoją pierwszą stronę internetową. Obecnie pracuje jako backend & mobile developer, rozwijając kilka ogólnopolskich produktów o zasięgu blisko 15 milionów użytkowników. Prywatnie maniak optymalizacji, testów A/B, motoryzacji i architektury aplikacji.

Dodaj komentarz