Testy wydajnościowe – Notatka z nauki

W ramach rozwijania się oglądam i czytam różne materiały. Następnie wiedzę z nich umieszczam w Anki oraz w notatkach i uzupełniam własnymi przemyśleniami.

Materiał: Boiling Frogs 2020 – Sebastian Korczyk Testy Wydajnościowe – to proste (*) opowiada o etapach testów wydajnościowych. Zanotowałem z tego materiału:

• Idealny schemat testowania:
  • Plan testu
  • Ustawienie testu
  • Wykonanie testu
  • Analiza wyników i raport
• Pomylenie się w założeniach w testach wydajnościowych sprawia, że testujemy nie to, co chcemy, dochodzimy do złych wniosków, robimy niepotrzebne testy.
• Testy są proste, jeżeli:
  • Wiemy, co robimy i po co.
  • Środowisko testowe odzwierciedla dokładnie produkcyjne.
  • Zrobiliśmy to, co chcieliśmy zrobić.
• Testy:
  • Stress test – puszczany jest coraz większy ruch – pozwala znaleźć punkt (Plate point), w którym w systemie pojawiają się problemy.
  • Soak Test – puszczany przez dłuższy czas (np. tydzień) z ruchem z punktu Plate. Pokazują np. memory leak, zapychanie kolejek, wycieki zasobów.
  • Normal Expected Utilisation – test z ruchem normalnym na produkcji (lub prognozowanym jako normalny).
  • Spike Test – test z pojedynczym dużym ruchem (np. wysyłanie smsa w Sylwestra).
  • Peak Load Test – duży większy ruch przez jakiś czas (np. zakończenie miesiąca księgowego).
• Środowisko:
  • Maszyna z testem musi być tak samo obciążona jak produkcyjna i mieć taką samą konfigurację (infrastruktura i hardware, włączone zabezpieczenia, wersje oprogramowania).
  • Dane, uprawnienia i procesy w środowisku testowym powinny być takie same jak na produkcji (np. liczba wierszy w bazie danych).
• Nie testujmy sieci, lecz nasze oprogramowanie.
• System i sieć “rozgrzewają się”.
• Zwróć uwagę na to, czy nie działają inne procesy (usuwane logów, antywirus).
• Loguj tyle samo, co na produkcji. Testuj identyczną konfigurację z produkcyjną.
• Przygotuj checklistę, co należy zrobić przed testem oraz prowadź dziennik testów.
• Zbieraj różne wartości i miary. Bierz pod uwagę też percentyle.
• Zawsze staraj się minimalizować RTT (ang. Round Trip Time) – czas od wysłania zapytania do uzyskania odpowiedzi.
• Badaj, czy nie masz Memory Leak’a.
• Waliduj odpowiedzi, bo przy dużym ruchu, możesz dostawać z serwera szybko odpowiedź, ale o błędzie na serwerze!!!
• CPU często jest oczekujące, a nie pracujące, więc warto też patrzeć na loadavg (zwane inaczej saturacją CPU).
• Używaj do mierzenia czasu pojedynczych metod specjalnych bibliotek, a nie tylko liczenia czasu.
• Po każdej zmianie należy zmierzyć wyniki, aby wiedzieć dokładnie, co wpłynęło na zmianę wyników.
• Zwróć uwagę na błędy ludzkie:
  • Złe ustawienie testów.
  • Błędy poznawcze.
  • Pewność siebie.