load testing poczty

Load testing poczty to sprawdzenie, jaki wolumen wiadomości infrastruktura obsłuży bez utraty wydajności.

Zakres i cel testu obciążeniowego poczty

Load testing poczty polega na kontrolowanym generowaniu ruchu odpowiadającego rzeczywistemu korzystaniu z systemu wiadomości. Test może obejmować wysyłanie poczty przez SMTP, przyjmowanie wiadomości przez serwer odbiorczy oraz pobieranie ich przez klientów korzystających z IMAP albo POP3. W przypadku wysyłki trzeba rozróżnić port 587 przeznaczony do submission, zwykle z uwierzytelnianiem użytkownika, od portu 25 używanego przede wszystkim do transmisji między serwerami SMTP. Port 465 jest stosowany do SMTP over TLS, czyli połączenia szyfrowanego od chwili nawiązania sesji.

Celem badania nie jest samo ustalenie maksymalnej liczby wiadomości wysłanych w krótkim czasie. Należy sprawdzić, czy system zachowuje wymagany czas odpowiedzi, poprawnie obsługuje kolejkę, nie odrzuca prawidłowych żądań oraz nie powoduje nadmiernego wzrostu opóźnień przy jednoczesnym ruchu wychodzącym i przychodzącym. Test powinien uwzględniać wielkość wiadomości, liczbę odbiorców, załączniki, częstotliwość logowania klientów oraz sposób rozkładania ruchu między procesy i hosty obsługujące pocztę.

Model ruchu SMTP, IMAP i POP3

Wiarygodny scenariusz obciążeniowy wykorzystuje kilka typów wiadomości. Krótkie wiadomości tekstowe pozwalają ocenić narzut związany z obsługą połączeń i transakcji SMTP, natomiast większe wiadomości z załącznikami obciążają transfer sieciowy, pamięć operacyjną, system plików oraz mechanizmy skanowania treści. Trzeba również uwzględnić wiadomości kierowane do jednego odbiorcy, do wielu odbiorców oraz takie, które kończą się błędem tymczasowym i trafiają do ponownej próby dostarczenia.

Po stronie odbioru test może symulować równoczesne logowania IMAP, odczytywanie nagłówków, pobieranie treści, wyszukiwanie wiadomości i przenoszenie ich między folderami. POP3 ma prostszy model pracy, ponieważ klient zwykle pobiera wiadomości ze skrzynki, często usuwając je po udanym odbiorze. Dla obu protokołów należy mierzyć czas uwierzytelnienia, czas odpowiedzi na polecenia, liczbę aktywnych sesji oraz odsetek połączeń zakończonych błędem. Scenariusze powinny zawierać zarówno utrzymywane sesje, jak i krótkie połączenia tworzone seryjnie.

Metryki ujawniające przeciążenie infrastruktury

Podstawową miarą jest przepustowość wyrażona liczbą wiadomości na sekundę lub minutę, ale sama wartość throughputu nie wystarcza. Podczas testu należy zapisywać opóźnienie od przyjęcia wiadomości przez SMTP do umieszczenia jej w skrzynce odbiorczej, czas odpowiedzi serwera na poszczególne operacje oraz wartości percentyli, na przykład p50, p95 i p99. Średnia może wyglądać poprawnie mimo tego, że niewielka część żądań trwa wielokrotnie dłużej i powoduje przekroczenie ustalonego czasu obsługi.

Warto obserwować długość kolejki pocztowej, liczbę ponowień dostarczenia, odpowiedzi SMTP z kodami 4xx i 5xx, liczbę aktywnych sesji oraz zużycie procesora, pamięci, przestrzeni dyskowej i operacji wejścia-wyjścia. Istotne są także limity deskryptorów plików, liczba dostępnych połączeń do usług pomocniczych oraz przepustowość interfejsu sieciowego. Jeżeli system korzysta z TLS, należy uwzględnić koszt negocjacji szyfrowania i sprawdzić, czy obciążenie procesora nie powoduje wzrostu czasu ustanawiania sesji. Każdy pomiar powinien mieć zapisany poziom obciążenia, konfigurację testu i wynik, aby można było porównać kolejne uruchomienia.

Bezpieczne wykonanie i interpretacja wyników

Test obciążeniowy poczty powinien być wykonywany na odseparowanym środowisku albo na kontrolowanym systemie z użyciem adresów testowych. Generator nie może przypadkowo wysyłać wiadomości do zewnętrznych odbiorców, ponieważ stworzyłoby to rzeczywisty ruch, którego skutków nie da się cofnąć. Należy ustalić maksymalny poziom obciążenia, czas trwania próby, rozmiary wiadomości, liczbę równoległych sesji oraz kryteria przerwania. Obciążenie zwykle zwiększa się stopniowo: od ruchu bazowego, przez poziom docelowy, aż do momentu pojawienia się mierzalnych opóźnień lub błędów.

Wynik należy oceniać względem zdefiniowanych progów, a nie względem pojedynczego rekordu przepustowości. Przykładowo system może przyjmować wiadomości bez błędów, ale jednocześnie utrzymywać rosnącą kolejkę, co oznacza, że chwilowa wydajność wejściowa przekracza zdolność dalszego dostarczania. Z kolei błędy uwierzytelniania przy dużej liczbie sesji mogą wskazywać na limit usługi logowania, a nie na problem z samym SMTP. Po zmianie konfiguracji test trzeba powtórzyć tym samym scenariuszem i porównać przepustowość, percentyle opóźnień, błędy oraz zużycie zasobów, aby odróżnić trwałą poprawę od przypadkowej różnicy pomiarowej.