Jak sprawdzić czas odpowiedzi serwera

Czas odpowiedzi, TTFB i ładowanie strony to nie ta sama liczba

Te terminy są używane zamiennie, a odpowiadają na różne pytania:

• Czas połączenia to rozwiązanie DNS plus uzgadnianie TCP plus uzgadnianie TLS. To głównie kwestia odległości i jakości sieci, a kod samego serwera nie ma z tym nic wspólnego.
• Time to first byte (TTFB) to moment, w którym dociera pierwszy bajt odpowiedzi, mierzony od początku żądania. Obejmuje czas połączenia plus przetwarzanie po stronie serwera: routing, zapytania do bazy danych, renderowanie szablonu, ewentualne wywołania API wyżej w łańcuchu.
• Czas przetwarzania serwera to TTFB minus czas połączenia. To jest ta część, którą możesz naprawić w swojej aplikacji.
• Czas ładowania strony to wszystko: HTML, a potem każdy obraz, arkusz stylów, skrypt i czcionka, które pobiera przeglądarka, plus praca związana z ich wyrenderowaniem. Strona może mieć znakomity TTFB, a mimo to ładować się osiem sekund.

Mylenie tych pojęć sprawia, że ludzie optymalizują nie to, co trzeba. Kompresja obrazów nic nie da wolnemu zapytaniu do bazy danych, a szybsza baza danych nic nie da stronie niosącej cztery megabajty JavaScriptu.

Mierzenie za pomocą curl

curl raportuje każdą fazę osobno, co pozwala jednym poleceniem rozdzielić koszt połączenia od kosztu serwera:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

Wszystkie wartości to sekundy liczone od początku żądania, więc każda kolejna obejmuje poprzednie. Przetwarzanie serwera to ttfb minus tls, albo minus connect przy zwykłym HTTP. Uruchom to trzy albo cztery razy: pierwsze żądanie może płacić koszt zimnego cache'u albo nowego połączenia, a jedna próbka to nie pomiar.

Dwie rzeczy warto trzymać w głowie. Ten pomiar dotyczy tylko dokumentu HTML, nie całej strony, więc zawsze będzie wyglądał szybciej niż test w przeglądarce. A niezbuforowana strona, strona po zalogowaniu albo wyniki wyszukiwania są często drastycznie wolniejsze niż strona główna, więc mierz adres URL, na którym Ci zależy, a nie /.

Co uchodzi za normę

Nie ma jednego uniwersalnego progu. Te przedziały to rozsądny punkt wyjścia dla żądania dokumentu mierzonego z lokalizacji blisko Twoich odwiedzających:

• Poniżej 200 ms. Szybko. Typowe dla treści statycznej, ciepłego cache'u albo brzegu CDN odpowiadającego bezpośrednio.
• 200 do 500 ms. Normalne dla dynamicznej strony wykonującej zapytanie do bazy danych. Nikt tego nie zauważa.
• Od 500 ms do 1 s. Zauważalne. Zwykle zapytanie wymagające indeksu, niezbuforowany szablon albo wolne wywołanie wyżej w łańcuchu.
• Od 1 do 3 s. Użytkownicy to czują, a wyszukiwarki to mierzą. Warto traktować to jako defekt.
• Powyżej 3 s. Coś jest nie tak: przeciążony serwer, blokada, przekroczenie czasu usługi wyżej w łańcuchu albo żądanie wykonujące dużo więcej pracy, niż powinno.

O wiele bardziej użyteczne jest porównanie z samym sobą. Strona, która miesiąc temu odpowiadała w 300 ms, a dziś odpowiada w 900 ms, ma konkretną przyczynę, która pojawiła się w międzyczasie, i wiedza o tym jest warta więcej niż jakikolwiek opublikowany benchmark.

Dlaczego to zależy od lokalizacji

Odległość kosztuje czas i nie da się tego zoptymalizować. Każdy przelot w obie strony między klientem a serwerem trwa co najmniej tyle, na ile pozwala fizyczna trasa, a połączenie TLS wymaga kilku przelotów w obie strony, zanim pierwszy bajt odpowiedzi w ogóle może wystartować. Dlatego ten sam serwer może odpowiadać w 150 ms lokalnie i w 700 ms z innego kontynentu, wykonując dokładnie tę samą pracę.

Routing też ma znaczenie, i jest mniej przewidywalny niż odległość: ruch między dwiema sieciami może iść słabą trasą, która dodaje opóźnienie tylko dla jednego regionu, nie dla innych. Jeśli używasz CDN, niektóre lokalizacje są obsługiwane z pobliskiej zbuforowanej kopii, podczas gdy inne nie trafiają w cache i płacą pełną trasę do serwera źródłowego, co daje szeroki rozrzut wyników między lokalizacjami dla tego samego adresu URL.

Mierz więc stamtąd, gdzie są Twoi użytkownicy, a nie stamtąd, gdzie jest Twój serwer, i porównuj podobne z podobnym. Liczba bez przypisanej lokalizacji nie jest porównywalna z niczym.

Kiedy powolność oznacza awarię

Niektóre spowolnienia to ostrzeżenie, a nie problem z wydajnością:

• Czas odpowiedzi rosnący stale pod obciążeniem oznacza, że serwer jest przeciążony. Kończy się to timeoutami, a nie tylko wolnymi stronami.
• Czasy skupione dokładnie przy 30 lub 60 sekundach to timeouty, nie powolność. Coś wyżej w łańcuchu nie odpowiada, a proxy czeka na swój limit, zanim podda się z kodem 504.
• Szybko przez większość czasu z okazjonalnymi ogromnymi skokami zwykle wskazuje na blokadę, zadanie cron, backup albo wygasający cache, który wszystkie żądania próbują odbudować jednocześnie.
• Wolno tylko dla zalogowanych użytkowników oznacza, że cache obsługuje ruch anonimowy i ukrywa pod spodem naprawdę wolną aplikację.
• Wolno tylko z jednego regionu to problem sieci albo CDN, nie aplikacji, i żadna ilość pracy po stronie backendu tego nie naprawi.

Zauważenie dnia, w którym coś się zmieniło

Pojedynczy pomiar mówi tylko o tym, co stało się dla jednego żądania, z jednego miejsca, w jednej chwili, a czas odpowiedzi to dokładnie ten rodzaj metryki, która się rozjeżdża, zamiast nagle się łamać. Zaplanowane kontrole mierzą ten sam adres URL z tych samych lokalizacji w sposób ciągły, przechowują historię, dzięki której możesz wskazać dzień, w którym coś się zmieniło, i alertują, gdy czas przekroczy próg, zamiast czekać na skargę klienta. HostTracker wykonuje takie kontrole z ponad 300 punktów kontrolnych w 158 miastach, więc regionalne spowolnienie jest widoczne jako takie. Uruchom kontrolę już teraz za pomocą narzędzia do kontroli HTTP. Gdy serwer jest szybki, a strona wciąż nie, resztę odpowiedzi znajdziesz w tekście jak sprawdzić szybkość strony.