czas odpowiedzi serwera

Czas odpowiedzi serwera to okres mierzony od wysłania żądania do otrzymania odpowiedzi z infrastruktury.

Jak definiuje się czas odpowiedzi serwera

Czas odpowiedzi serwera opisuje, ile trwa obsługa żądania od chwili jego wysłania przez klienta do chwili otrzymania odpowiedzi. W praktyce nie jest to zawsze jedna, identycznie mierzona wartość. Wynik zależy od punktu rozpoczęcia pomiaru, momentu uznanego za zakończenie oraz tego, czy analizowane jest połączenie lokalne, sieciowe, szyfrowane czy realizowane przez przeglądarkę internetową. Dla żądania HTTP odpowiedzią może być między innymi kod 200, przekierowanie 301 lub 302, błąd klienta 404 albo błąd serwera 500.

Na całkowity czas składa się kilka etapów. Klient może najpierw wykonywać wyszukiwanie DNS, następnie zestawić połączenie TCP, a przy HTTPS także przeprowadzić negocjację TLS. Dopiero później serwer odbiera żądanie, przekazuje je do aplikacji, może odczytać dane z pamięci lub bazy danych, wygenerować treść i rozpocząć jej przesyłanie. Opóźnienie sieciowe, obciążenie procesora, oczekiwanie na dysk, blokada w bazie danych oraz kolejka żądań mogą zwiększyć wynik, nawet gdy sam komputer użytkownika działa prawidłowo.

TTFB, opóźnienie sieci i czas przesyłania treści

Jedną z często używanych miar jest TTFB, czyli Time to First Byte. Oznacza ona czas od rozpoczęcia żądania do odebrania pierwszego bajtu odpowiedzi. TTFB obejmuje więc nie tylko pracę aplikacji, lecz także etapy potrzebne do dotarcia żądania do serwera i rozpoczęcia odpowiedzi. Nie opisuje natomiast całkowitego czasu pobierania dużego pliku lub całej strony. Serwer może szybko wysłać pierwszy fragment, a następnie długo przesyłać pozostałą zawartość.

Warto rozdzielać czas oczekiwania od czasu transferu. Mała strona HTML może zostać wygenerowana szybko, ale jej pobranie opóźnią problemy z trasą sieciową albo przeciążone łącze. Z kolei duży plik może mieć krótki TTFB, lecz długi czas pobierania wynikający z rozmiaru danych i dostępnej przepustowości. W przypadku HTTPS dodatkowe opóźnienie może pojawić się podczas pierwszego uzgadniania TLS, natomiast ponowne użycie istniejącego połączenia może ograniczyć liczbę operacji potrzebnych przed wysłaniem żądania.

Co zwiększa opóźnienie po stronie serwera

Serwer odpowiada wolniej, gdy aplikacja wykonuje kosztowne obliczenia, czeka na zewnętrzne API albo pobiera dane z wolnego nośnika. Przyczyną może być również nieefektywne zapytanie do bazy danych, brak odpowiedniego indeksu, blokada transakcji lub wyczerpanie puli połączeń. Jeśli wiele żądań jednocześnie korzysta z ograniczonej liczby procesów, wątków albo połączeń, część z nich oczekuje w kolejce. Wtedy średni czas odpowiedzi rośnie, mimo że pojedyncza operacja może być krótka.

Do podstawowego rozróżnienia etapów można użyć narzędzia curl. Przykładowe polecenie curl -o NUL -s -w "DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" https://example.com/ pokazuje czasy raportowane przez klienta curl w środowisku Windows, gdzie NUL odrzuca pobieraną treść. W innych systemach operacyjnych odpowiednikiem jest /dev/null. Taki pomiar nie wskazuje automatycznie winnego opóźnienia, ale pomaga sprawdzić, czy problem występuje podczas DNS, zestawiania połączenia, oczekiwania na pierwszy bajt czy pełnego transferu.

Interpretacja pomiarów i diagnostyka powtarzalności

Pojedynczy wynik nie wystarcza do oceny stabilności serwera. Opóźnienie zmienia się zależnie od lokalizacji klienta, pory dnia, użytej trasy sieciowej, obciążenia serwera oraz rodzaju żądania. Dlatego warto wykonać serię pomiarów i porównać medianę z wartościami skrajnymi. Mediana pokazuje typowy wynik mniej podatny na pojedynczy incydent, a wysokie wartości maksymalne mogą wskazywać na chwilowe przeciążenia, problemy z siecią albo zatrzymania procesu oczekującego na zasoby.

Podczas analizy należy sprawdzić, czy test dotyczy tego samego adresu, protokołu, zasobu i metody HTTP. Inny rezultat może dać żądanie do statycznego pliku, a inny do dynamicznego endpointu wykonującego zapytanie do bazy danych. Trzeba także odnotować kod statusu, rozmiar odpowiedzi oraz ewentualne przekierowania, ponieważ pomiar adresu przekierowującego może obejmować więcej niż jedno żądanie. Jeżeli opóźnienie rośnie razem z liczbą równoczesnych klientów, wskazuje to na ograniczenie przepustowości lub zasobów po stronie serwera, a nie na stałą cechę pojedynczego połączenia.