Jak wykonać optymalizację konfiguracji PHP-FPM pod WordPress

Wprowadzenie – znaczenie PHP-FPM dla wydajności WordPress

PHP-FPM zarządza procesami wykonującymi kod PHP. Właściwa konfiguracja pomaga ograniczyć kolejki i zużycie zasobów, ale nie zastąpi optymalizacji bazy danych, wtyczek czy pamięci podręcznej. Efekt zależy od istniejącej konfiguracji i rodzaju ruchu.

Przed zmianami ustal wersję PHP obsługującą daną stronę, aktywną pulę, jej konfigurację i sposób zarządzania usługą. W hostingu współdzielonym skorzystaj z panelu lub pomocy administratora. Wybierz wspieraną wersję PHP zgodną z WordPressem, motywem i wtyczkami; sprawdź okres wsparcia PHP i wymagania WordPressa.

Zrozumienie architektury PHP-FPM i jego procesów

Proces główny FPM zarządza pulami procesów roboczych. Każdy worker obsługuje jednocześnie jedno żądanie FastCGI. Gdy wszystkie są zajęte, kolejne połączenia mogą czekać w kolejce lub zakończyć się błędem. Strony obsłużone w całości z cache nie muszą angażować workera PHP.

Osobne pule pozwalają ustawić różne limity i użytkowników, ale nie zapewniają pełnej izolacji bezpieczeństwa ani niezależności zasobów. Ograniczeniem może być także CPU, baza danych lub zewnętrzne API.

Optymalizacja ustawień pm dla WordPress

• static: utrzymuje stałą liczbę procesów równą pm.max_children; może pasować do przewidywalnego obciążenia, ale zajmuje pamięć również bez ruchu.
• dynamic: dostosowuje liczbę workerów i utrzymuje zapas bezczynnych procesów. Na starcie tworzy pm.start_servers; zapasem sterują pm.min_spare_servers i pm.max_spare_servers.
• ondemand: tworzy procesy na żądanie i usuwa bezczynne po pm.process_idle_timeout. Może oszczędzać pamięć przy nieregularnym ruchu, także w produkcji, kosztem opóźnienia tworzenia procesów.

W każdym trybie pm.max_children określa stałą lub maksymalną liczbę workerów. Liczba dziennych odwiedzin nie wystarcza do jej wyliczenia: liczą się równoczesne żądania PHP, czas ich obsługi i dostępne zasoby.

Konfiguracja liczby procesów dla różnych typów ruchu

Najpierw określ budżet RAM dla danej puli, pozostawiając zapas dla systemu, serwera WWW, bazy danych, cache, innych pul i skoków obciążenia. Oszacuj pamięć workera podczas reprezentatywnych, także cięższych żądań. RSS poszczególnych procesów zawiera pamięć współdzieloną, więc jego prosta suma może ją wielokrotnie policzyć; jeśli to możliwe, wykorzystaj PSS i porównaj pomiary z całkowitym zużyciem serwera.

Przybliżenie: budżet pamięci puli / ostrożne oszacowanie pamięci na worker = początkowy górny pułap liczby procesów. Przykładowo, przy budżecie 1200 MB i oszacowaniu 100 MB na proces wynik wynosi 12. To wyłącznie przykład rachunkowy, nie zalecenie dla konkretnego serwera. Suma budżetów wszystkich pul musi mieścić się w zasobach maszyny.

Sprawdź kolejkę, ostrzeżenia o osiągnięciu pm.max_children, pamięć, CPU i bazę danych w szczycie. Zwiększaj limit tylko wtedy, gdy kolejka rzeczywiście wynika z braku workerów i pozostały zasoby. Wysokie CPU samo w sobie nie jest powodem do zwiększenia liczby procesów.

Ustawienia timeout i limitów pamięci dla stabilności

• memory_limit ogranicza pamięć przydzielaną przez PHP skryptowi, a nie całkowity RSS procesu. Wyższy limit nie oznacza, że każdy worker go zużyje, ale zwiększa możliwe obciążenie przy równoległych żądaniach.
• max_execution_time ogranicza czas wykonania skryptu według zasad PHP; na systemach Unix czas niektórych operacji zewnętrznych nie jest wliczany. Nie jest więc uniwersalnym limitem czasu odpowiedzi.
• request_terminate_timeout może zakończyć workera obsługującego zbyt długie żądanie; 0 wyłącza ten limit. Domyślnie nie działa po fastcgi_finish_request() ani podczas funkcji zamykających, chyba że włączono request_terminate_timeout_track_finished.
• request_slowlog_timeout uruchamia zapis śladu stosu do slowlog po przekroczeniu progu; nie kończy żądania.

Limity dobieraj na podstawie błędów i pomiarów, także dla WooCommerce. Uwzględnij timeouty proxy i serwera WWW. Zbyt krótki limit może przerwać import lub operację zamówienia; zbyt długi wiąże workery. Nie zakładaj, że przerwana operacja została w całości wycofana. Wartości ustawione przez php_admin_value nie mogą być nadpisane przez aplikację.

Monitorowanie wydajności PHP-FPM za pomocą status page

Dyrektywa pm.status_path definiuje ścieżkę statusu puli, ale sama nie konfiguruje dostępu przez serwer WWW. Status może ujawniać szczegóły żądań i zasobów: udostępnij go tylko zaufanemu monitoringowi, ogranicz dostęp na serwerze WWW i sprawdź, czy żądania z Internetu są odrzucane. Nie wystawiaj gniazda FastCGI publicznie – dostęp do niego może umożliwić wykonanie kodu.

Obserwuj active processes, idle processes, listen queue, max children reached i slow requests. Porównuj zmiany liczników w czasie oraz z logami, CPU, RAM i czasem odpowiedzi. Progi alertów dobierz do obciążenia; pojedynczy odczyt nie wystarcza do diagnozy.

Implementacja pul procesów dla różnych stron i aplikacji

Oddzielne pule pozwalają przypisać stronie własnego użytkownika, gniazdo i limity. Nie są jednak pełną granicą bezpieczeństwa: pule współdzielą m.in. instancję OPcache, a zbyt wysokie łączne limity nadal mogą wyczerpać pamięć. Separacja wymaga również właściwych użytkowników i uprawnień plików oraz kontroli dostępu do gniazd.

Na Debianie pliki puli często znajdują się w /etc/php/<wersja>/fpm/pool.d/, ale ścieżka i sposób zarządzania zależą od instalacji. W panelach hostingowych konfiguracja może być generowana automatycznie: korzystaj z przewidzianego mechanizmu, aby zmiana nie została nadpisana. Nie kopiuj konfiguracji ani użytkownika innej domeny bez sprawdzenia uprawnień.

Przed wdrożeniem zachowaj kopię konfiguracji i zaplanuj wycofanie. Sprawdź składnię właściwą binarką i plikiem konfiguracji FPM, np. php-fpm8.3 -t -y /etc/php/8.3/fpm/php-fpm.conf na zgodnej instalacji Debiana. Przykładowa wersja i ścieżka nie są uniwersalne. Dopiero po poprawnym teście zastosuj zmianę zgodnie z procedurą hostingu; przeładowanie usługi może wpływać na inne strony korzystające z tej instancji.

Optymalizacja ustawień slowlog dla debugowania

W konfiguracji właściwej puli ustaw request_slowlog_timeout i ścieżkę slowlog dostępną dla FPM, zgodnie z uprawnieniami serwera. Próg, np. 5s, jest punktem wyjścia do diagnostyki, nie uniwersalną wartością. Sprawdź zapis i zadbaj o rotację oraz ograniczenie dostępu do logów.

Slowlog zapisuje ślad stosu PHP dla wolnego żądania. Może wskazać wtyczkę, zapytanie do bazy lub oczekiwanie na API, ale sam nie dowodzi przyczyny. Koreluj wpisy z logami aplikacji i metrykami, uważając na potencjalnie wrażliwe ścieżki i dane w logach.

Testowanie wydajności przy różnych konfiguracjach PHP-FPM

1. Zmierz stan wyjściowy: opóźnienia, błędy, kolejkę FPM oraz zużycie CPU i pamięci. Uwzględnij zarówno ruch z cache, jak i żądania dynamiczne.
2. Testuj w odizolowanym środowisku za zgodą właściciela. Zabezpiecz dane osobowe, wyłącz rzeczywiste płatności, e-maile i integracje zewnętrzne. Nie obciążaj produkcji bez zgody i planu awaryjnego.
3. Dobierz realistyczne scenariusze i stopniowo zwiększaj obciążenie. Porównuj m.in. percentyle czasu odpowiedzi, odsetek błędów, kolejkę i zasoby, a nie tylko średnią.
4. Zmieniaj jeden parametr naraz, powtórz pomiary i porównaj wyniki. Przy regresji przywróć poprzednią konfigurację zgodnie z przygotowaną procedurą.

Jeśli rośnie kolejka, sprawdź przyczynę przed zwiększeniem liczby workerów. Jeśli brakuje pamięci lub CPU jest przeciążony, dodatkowe procesy mogą pogorszyć sytuację. Przydatnym uzupełnieniem są testy szybkości backendu WordPress i diagnostyka OPcache.

Podsumowanie – skalowalne rozwiązania PHP-FPM dla WordPress

Dobierz tryb zarządzania procesami do ruchu, a pm.max_children do budżetu zasobów i pomiarów. Zabezpiecz monitoring, analizuj wolne żądania i sprawdzaj wyniki po każdej zmianie. Więcej workerów lub wyższe limity nie są celem samym w sobie.

Dokładny opis dyrektyw i ich wartości domyślnych znajdziesz w dokumentacji konfiguracji PHP-FPM.

Najczęstsze pytania o PHP-FPM i WordPress

Jak obliczyć liczbę procesów PHP-FPM dla WordPress?

Podziel budżet pamięci przeznaczony dla danej puli przez ostrożnie oszacowane zużycie pamięci jednego workera. Wynik jest punktem wyjścia: uwzględnij inne pule, CPU, bazę danych i wyniki testów.

Czy tryb ondemand nadaje się do produkcyjnego WordPressa?

Tak, może być przydatny przy niskim lub nieregularnym ruchu. Oszczędza pamięć, gdy pula jest bezczynna, ale tworzenie procesów może zwiększyć opóźnienie po okresie bezczynności.

Czy zwiększenie pm.max_children zawsze przyspiesza stronę?

Nie. Więcej procesów może pomóc przy kolejce i dostępnych zasobach, ale może też przeciążyć pamięć, CPU lub bazę danych. Zmianę trzeba uzasadnić pomiarami.

Jak monitorować PHP-FPM bez ujawniania danych?

Stronę statusu należy udostępnić wyłącznie zaufanemu monitoringowi i ograniczyć dostęp na serwerze WWW. Gniazdo FastCGI nie może być publicznie dostępne.

Czy WooCommerce wymaga stałych limitów pamięci i czasu?

Nie ma jednego bezpiecznego zestawu limitów dla każdego sklepu. Dobierz je do rzeczywistego zużycia i operacji, uwzględniając również limity serwera WWW oraz dostępne zasoby.