TTFB > 600 ms. Zacznij od ustawień, nie od karty kredytowej
Wykonam test TTFB i obciążeniowy po godzinie szczytu — jeśli czas odpowiedzi serwera przekroczy 600 ms, natychmiast przechodzę do analizy hostingu i konfiguracji równoważenia obciążenia.
Test i decyzja
TTFB 600 ms to moja czerwona linia przy stronach informacyjnych i sklepach o niskiej tolerancji opóźnień. Jeżeli masz stały wzrost czasu odpowiedzi po 18:00, nie kupuj droższego CPU od razu. Najpierw zdiagnozuj: obciążenie CPU, liczba aktywnych połączeń TCP, saturacja IOPS i wskaźnik cache hit ratio. W praktyce widziałem, że problem z 1200 ms potrafił zniknąć po zmianie konfiguracji równoważenia i ograniczeniu liczby jednoczesnych workerów PHP-FPM — ciężar spadł, IOPS spadły o 30–80% w zależności od przypadku.
Optymalizacja jako zarządzanie kosztami IOPS i połączeń
Myślenie: opóźnienia = pieniądze. Nawet drobne zmiany w PHP-FPM (pm = dynamic, ustawienie pm.max_children na podstawie dostępnej pamięci i średniego zużycia jednego procesu), cache (Redis/OPcache/HTTP cache) i indeksach bazy danych często dadzą lepszy ROI niż migracja na szybsze dyski. Przykład z praktyki: jedno zapytanie bez indeksu 3 s → po dodaniu indeksu 60 ms. To nie fantazja, to konkretna redukcja IOPS i liczby otwartych połączeń na serwerze bazodanowym.
Praktyczne kroki (backup → optymalizacja → test)
Krok 1 — backup. Zrób pełną kopię plików i bazy danych. Snapshot LVM/VM/volumów chmurowych + dump bazy to minimum. Miałem sytuację na jors.pl, gdzie błędna zmiana ustawień cache rozbiła sesje użytkowników; pełny snapshot i rollback trwały 12 minut i uratowały serwis przed kilkoma godzinami przestoju.
Krok 2 — testy w godzinie szczytu. Mierz TTFB i p95 latency.
Krok 3 — hosting i lokalizacja. Latencja sieciowa do bazy i CDN ma bezpośredni wpływ na TTFB. Przy ruchu z USA rozważyć replikę bazy w regionie, a przynajmniej CDN z cache TTL. Na etapie wyboru pamięci operacyjnej uwzględnić, jak ECC wpływa na stabilność — zobacz jak ECC zmienia charakter błędów pamięci.
Krok 4 — cache i PHP. OPcache z właściwą ustawioną pamięcią i invalidacją, Redis jako cache obiektów i Varnish/HTTP cache do redukcji zapytań do backendu. PHP-FPM: ustawienie pm.max_children = floor(available_RAM_for_php / avg_php_worker_mem) i pm.max_requests na 500–1000 ograniczy pamięciożerne leak'i i zmniejszy liczbę restartów.
Krok 5 — baza danych. EXPLAIN dla długich zapytań, sprawdzenie brakujących indeksów, ograniczenie JOIN-ów na dużych tabelach, partycjonowanie jeśli potrzebne. Monitoruj queries/sec i slow_query_log; dodanie właściwego indeksu często obniża IOPS i czas zapytania wielokrotnie.
Krok 6 — treść i sieć. Kompresja obrazów, Brotli/Gzip, optymalizacja HTML/JS, preload krytycznych zasobów i ustawienie nagłówków cache. CDN odciąża origin i obniża TTFB dla geograficznie rozproszonych użytkowników.
Detale, które rzeczywiście psują wydajność
Z mojego warsztatu: nieodpowiedni pm.max_children, brak limitów na liczby otwartych plików, brak indeksów w bazie, cache miss rate 80% i ciągłe swapowanie. Każdy z tych elementów działa jak ząb w maszynie — jedno niedopasowanie potrafi spowodować lawinę wzrostu IOPS i liczby połączeń. Sprawdzaj metryki hosta i kontenera (LXC/Docker) osobno; to, co wygląda OK na hoście, bywa tragedią w konteinerze.