Jak czytać statystyki hostingu i odróżnić problem strony od problemu serwera

Panel hostingu zwykle ma zakładkę ze statystykami, do której większość właścicieli stron nie zagląda, dopóki coś nie zacznie działać źle. A szkoda, bo to najlepsze źródło odpowiedzi na najważniejsze pytanie przy każdej awarii wydajności: czy zawiodła moja strona, czy serwer? Umiejętność czytania tych wykresów pozwala przestać zgadywać i zacząć naprawiać właściwą rzecz.

Ten artykuł uzupełnia dwa inne poradniki: jak sprawdzić szybkość hostingu i nie pomylić jej z problemem strony, który skupia się na pojedynczym pomiarze szybkości, oraz jak czytać limity hostingu, który wyjaśnia same parametry. Tutaj patrzymy na statystyki w czasie — bo to przebieg wykresu, a nie jedna liczba, zdradza źródło problemu.

Najpierw: statystyki mówią o wzorcach, nie o chwili

Pojedynczy pomiar to fotografia. Statystyki to film. Dopiero widząc, jak zużycie zasobów zmienia się w czasie, rozpoznasz różnicę między „serwer jest chronicznie za słaby”, „coś dzieje się codziennie o tej samej porze” a „raz w tygodniu ktoś zalewa nas ruchem”. Zawsze zaczynaj od pytania: jak wygląda linia na wykresie w ciągu doby i tygodnia, a nie ile wynosi teraz.

CPU i procesy PHP: kto zjada moc

Wykres zużycia procesora i liczby procesów PHP to serce diagnozy. Interpretuj go tak:

• Płaska linia przy suficie limitu przez większość doby — konto chronicznie brakuje mocy. To sygnał, że pakiet jest za mały albo strona robi zbyt dużo pracy niecache'owanej.
• Regularne skoki o stałej porze — najczęściej zaplanowane zadania: cron, kopie, importy, wysyłki. Problem strony/konfiguracji, nie serwera.
• Nagły, jednorazowy skok — zwykle skok ruchu albo bot. Zestaw go z wykresem odwiedzin.

Jeśli CPU stale ociera się o limit, żadna optymalizacja obrazków tego nie naprawi — to rozmowa o mocniejszym planie lub VPS.

Pamięć i transfer: dwa różne sygnały

Zużycie pamięci rosnące do limitu przy cięższych operacjach wskazuje na zbyt niski memory_limit albo pamięciożerne wtyczki — to warstwa strony. Transfer (ruch wychodzący) rośnie wraz z liczbą i wagą wyświetlanych plików. Jeśli transfer wystrzelił bez wzrostu realnych odwiedzin, podejrzewaj hotlinking obrazków, scrapery albo zbyt ciężkie multimedia. To również problem strony/treści, nie serwera.

Liczba żądań i odwiedzin: zestawiaj wykresy

Najcenniejsze wnioski płyną z nakładania na siebie dwóch wykresów: zużycia zasobów i liczby żądań. Możliwe scenariusze:

• Zasoby rosną razem z ruchem — serwer po prostu wykonuje pracę proporcjonalną do popularności. Jeśli przy dużym ruchu uderzasz w sufit, potrzebujesz więcej mocy.
• Zasoby rosną bez wzrostu realnego ruchu — sygnał, że coś jest nieefektywne po stronie strony (ciężkie zapytania, brak cache) albo że ruch pochodzi od botów, nie ludzi.
• Ruch rośnie, a zasoby prawie nie — działa cache i wszystko jest zdrowe.

Statystyki błędów: 5xx kontra 4xx

Wiele paneli pokazuje liczbę odpowiedzi z podziałem na kody. To szybki rozgraniczik winy:

• Błędy 5xx (500, 502, 503) — problem po stronie serwera lub aplikacji: przekroczone limity, zabity proces PHP, timeout. Rosnący udział 5xx w godzinach szczytu to klasyczny objaw zbyt małych zasobów.
• Błędy 4xx (404, 403) — najczęściej problem strony: martwe odnośniki, złe przekierowania, zablokowane zasoby. Duża liczba 404 od jednego adresu to często bot skanujący.

Gdy widzisz falę błędów, nie zgaduj przyczyny — sięgnij do logów. Pokazujemy to w tekście logi serwera: gdzie szukać przyczyny błędu 500, 403 i białej strony.

Prosty schemat wnioskowania

Nie polegaj tylko na panelu

Statystyki hostingu pokazują perspektywę serwera. Warto zestawić je z zewnętrznym monitoringiem dostępności, który mierzy stronę „z zewnątrz” i wyłapuje przestoje niezależnie od tego, co twierdzi panel. Jak go ustawić i czemu ufać, opisujemy w artykule monitoring uptime: jak sprawdzać, czy hosting naprawdę działa stabilnie. Dwa niezależne źródła danych to najprostszy sposób, by nie dać się zmylić.

Podsumowanie

Statystyki hostingu przestają być tłem, gdy nauczysz się czytać je jak film, nie zdjęcie. Nakładaj na siebie wykresy zasobów i ruchu, patrz na kształt linii w skali doby i tygodnia, rozróżniaj błędy 5xx od 4xx i zestawiaj panel z niezależnym monitoringiem. Wtedy pytanie „to strona czy serwer?” przestaje być zgadywanką: chroniczny sufit CPU i rosnące 5xx wołają o więcej mocy, a skoki bez wzrostu ruchu i błędy 4xx odsyłają Cię do własnej strony. Właściwa diagnoza to połowa naprawy.