Liczba PHP workers mówi, ile żądań PHP może być wykonywanych równolegle w danej konfiguracji, ale sama wartość „10 workers” nie wystarcza do oceny, czy hosting będzie szybki. Ten sam limit może wystarczyć stronie z krótkimi żądaniami i okazać się zbyt mały przy wolnych zapytaniach do bazy, zewnętrznych API albo ciężkich operacjach WordPressa.
Najpierw trzeba też ustalić, co operator dokładnie nazywa PHP workers. W zależności od stosu serwera może chodzić o procesy PHP-FPM, procesy LSAPI/LiteSpeed albo inny mechanizm współbieżności. Nie należy automatycznie utożsamiać tej liczby z CloudLinux EP lub NPROC, bo EP i NPROC są odrębnymi limitami, a sposób działania EP różni się również między Apache i LiteSpeed.
Co to jest PHP worker?
W praktyce hostingowej określenie PHP worker zwykle oznacza proces lub slot wykonujący kod PHP dla żądania dynamicznego. Gdy taki worker obsługuje żądanie, pozostaje zajęty do chwili zakończenia pracy albo przerwania jej przez limit lub timeout. W PHP-FPM najbliższym odpowiednikiem takiego limitu jest zwykle pm.max_children, czyli maksymalna liczba równocześnie obsługiwanych żądań przez pulę FPM; marketingowa liczba operatora nie musi jednak oznaczać dokładnie tej dyrektywy.
Jeżeli wszystkie dostępne workers są zajęte, kolejne dynamiczne żądanie może czekać na wolny proces albo zostać obsłużone zgodnie z zasadami konkretnej konfiguracji serwera. Dlatego liczba workers wpływa przede wszystkim na współbieżność, a nie na szybkość pojedynczego wykonania PHP.
To ważne rozróżnienie: zwiększenie liczby workers nie przyspiesza automatycznie jednego wolnego zapytania. Pozwala natomiast obsługiwać więcej pracy równocześnie — o ile pozostałe zasoby, takie jak CPU i pamięć, także na to pozwalają.
Dlaczego 10 PHP workers nie oznacza 10 użytkowników?
Użytkownik może wykonać kilka żądań dynamicznych, a część odsłon może zostać obsłużona z cache bez uruchamiania pełnego PHP. Z drugiej strony jedno wolne żądanie może zajmować worker przez kilka sekund. Dlatego liczby użytkowników online i PHP workers nie da się przeliczać 1:1.
Przykład hipotetyczny: jeśli dynamiczne żądanie trwa 100 ms, jeden worker może zwolnić się bardzo szybko i obsłużyć kolejną pracę. Jeżeli podobne żądanie trwa 5 sekund, ten sam worker jest zajęty pięćdziesiąt razy dłużej. Przy tej samej liczbie odwiedzających ryzyko kolejki jest wtedy znacznie większe.
Ten przykład nie jest kalkulatorem przepustowości hostingu. Pokazuje tylko zależność: liczba równoległych workers i czas obsługi żądania muszą być analizowane razem.
PHP workers a EP i NPROC w CloudLinux
PHP workers, EP i NPROC to nie są automatycznie te same wartości. W CloudLinux EP oznacza liczbę wejść do środowiska LVE, a NPROC maksymalną liczbę procesów w LVE; oba limity konfiguruje się oddzielnie.
W konfiguracji Apache nowe żądanie CGI/PHP może zwiększać EP. Przy LiteSpeed implementacja EP wygląda inaczej: licznik może rosnąć wraz z procesami głównymi LSAPI, podczas gdy procesy potomne mogą obsługiwać kolejne żądania bez prostego przełożenia 1:1 na EP. To jeden z powodów, dla których marketingowej liczby „PHP workers” nie powinno się zamieniać bezpośrednio na limit EP. Sposób liczenia Entry Processes zależy tu od użytego stosu serwera.
NPROC ma jeszcze inny zakres: liczy procesy działające w LVE i jest raportowany niezależnie od EP, wraz z własnym wykorzystaniem oraz faults w statystykach CloudLinux.
| Parametr | Co opisuje | Czego nie zakładać |
|---|---|---|
| PHP workers | Liczbę równoległych procesów lub slotów PHP według konfiguracji operatora | Że zawsze odpowiada liczbie EP albo NPROC |
| EP | Entry Processes w CloudLinux, czyli wejścia do LVE | Że oznacza liczbę użytkowników online |
| NPROC | Maksymalną liczbę procesów w LVE | Że dotyczy wyłącznie PHP |
| CPU/SPEED | Przydział CPU dostępny dla konta | Że większa liczba workers daje automatycznie więcej CPU |
| PMEM | Limit pamięci fizycznej procesów konta | Że każdy dodatkowy worker będzie miał osobny pełny limit RAM |
Kiedy większa liczba PHP workers może pomóc?
Więcej workers może pomóc wtedy, gdy problemem jest kolejka równoległych dynamicznych żądań, a CPU, pamięć i pozostałe limity mają jeszcze zapas. Typowy sygnał to sytuacja, w której pojedyncze żądania działają poprawnie, ale przy kilku równoczesnych operacjach rośnie oczekiwanie na dostępny proces PHP.
Dotyczyć to może między innymi WooCommerce, zaplecza WordPressa, dynamicznych wyszukiwarek i innych funkcji, których nie można w pełni obsłużyć z page cache. Nie oznacza to jednak, że każda taka strona potrzebuje wysokiego limitu workers. Krótkie żądania zwalniają procesy szybciej niż wolne.
Jeżeli wyższy pakiet zwiększa workers, ale jednocześnie strona już dochodzi do limitu CPU albo PMEM, dodatkowa współbieżność może nie dać oczekiwanego efektu. Trzeba sprawdzić cały zestaw zasobów, nie jeden parametr z tabeli cenowej.
Kiedy więcej workers nie rozwiąże problemu?
Jeżeli jedno żądanie PHP jest wolne z powodu ciężkiego zapytania do bazy, zewnętrznego API albo nieefektywnej funkcji aplikacji, większa liczba workers może jedynie pozwolić uruchomić więcej takich wolnych operacji równocześnie. Nie skraca automatycznie czasu każdej z nich.
Podobnie wygląda sytuacja przy ograniczeniu CPU. W CloudLinux SPEED jest osobnym limitem procesora, a po jego osiągnięciu praca jest dławiona zgodnie z mechanizmem limitu CPU. Większa liczba równoległych procesów bez dodatkowego CPU może zwiększyć konkurencję o ten sam przydział.
Przy pamięci sytuacja jest analogiczna: więcej aktywnych procesów może zwiększać łączne zużycie PMEM. W CloudLinux PMEM jest odrębnym limitem pamięci fizycznej używanej przez procesy konta.
Jak sprawdzić, czy naprawdę brakuje PHP workers?
Najlepszy dowód to nie sama liczba z cennika, lecz obserwacja zachowania podczas problemu. Potrzebujesz odpowiedzi na trzy pytania:
- Czy w czasie spowolnienia wszystkie workers były zajęte albo żądania czekały na wolny proces PHP?
- Czy CPU, PMEM, NPROC, EP, I/O lub IOPS nie były wtedy głównym ograniczeniem?
- Czy pojedyncze żądania są wystarczająco szybkie, czy każde z nich samo w sobie trwa długo?
Jeżeli operator pokazuje tylko limit workers, poproś również o sposób jego raportowania. Sama odpowiedź „pakiet ma 20 zamiast 10 workers” nie mówi jeszcze, czy obecny problem wynika z braku współbieżności. Jeżeli operator używa PHP-FPM i udostępnia jego statystyki, pomocne są między innymi listen queue, czyli liczba żądań oczekujących na wolny proces, oraz max children reached, informujące o osiąganiu maksymalnej liczby procesów puli. Oficjalny status PHP-FPM raportuje te pola wraz z liczbą procesów aktywnych i bezczynnych.
Jeżeli równocześnie widzisz 508 lub 503, wykorzystaj odpowiednie poradniki: 508 Resource Limit Reached i 503 Service Unavailable. Szersze rozróżnienie zasobów opisuje poradnik o CPU, RAM, procesach i I/O.
PHP workers a cache w WordPressie
Page cache zmniejsza liczbę żądań wymagających pełnego wykonania WordPressa. Jeżeli niezalogowany użytkownik otrzymuje gotową odpowiedź z cache, PHP może w ogóle nie wykonywać pełnej ścieżki aplikacji dla tego wejścia. Page cache pozwala serwować statyczną wersję strony bez ponownego generowania jej przy każdym żądaniu.
Dlatego liczba workers jest zwykle ważniejsza tam, gdzie cache nie może przejąć większości pracy: w panelu administracyjnym, koszyku, koncie użytkownika, dynamicznych wyszukiwarkach i przy innych spersonalizowanych żądaniach.
Nie wynika z tego, że „cache zastępuje workers”. Cache ogranicza liczbę dynamicznych wykonań, a workers określają współbieżność tych wykonań, które nadal muszą dojść do PHP.
PHP workers w WooCommerce — dlaczego temat pojawia się częściej?
WooCommerce ma więcej operacji dynamicznych niż prosta strona informacyjna. Koszyk, konto klienta, checkout, zapisy zamówień i część zapytań nie mogą być traktowane jak zwykła statyczna kopia strony dla wszystkich użytkowników. To zwiększa znaczenie równoległej obsługi PHP.
Nie daje to jednak uniwersalnej odpowiedzi typu „sklep potrzebuje co najmniej 10 workers”. Ruch, sposób cache, szybkość zapytań, liczba integracji i czas wykonania poszczególnych operacji różnią się między sklepami. Bez pomiaru kolejki i czasu pracy PHP taka liczba byłaby arbitralna.
Jak porównywać oferty z różną liczbą PHP workers?
Jeżeli dwóch operatorów podaje ten parametr, najpierw sprawdź, czy definiują go w ten sam sposób. Zapytaj, czy chodzi o procesy PHP-FPM, LSAPI/LiteSpeed czy inny limit oraz czy wartość dotyczy konta, domeny czy konkretnej wersji usługi.
Następnie porównaj workers razem z CPU, PMEM, NPROC i — jeśli ma zastosowanie — EP. Są to odrębne ograniczenia w modelu LVE. Oferta z większą liczbą workers, ale mniejszym CPU lub pamięcią nie jest automatycznie wydajniejsza dla WordPressa.
Sprawdź również odnowienie, backup, wersje PHP, przestrzeń i pozostałe wymagania strony. Liczba workers jest jednym parametrem technicznym, nie pełnym rankingiem hostingu.
Jak zapytać operatora o PHP workers?
Proszę wyjaśnić, co w tym pakiecie oznacza limit [X] PHP workers: jakiego mechanizmu PHP dotyczy i czy jest liczony dla całego konta, domeny czy osobnej puli. Czy w czasie [data i godzina problemu] obecny limit workers był w pełni wykorzystany albo żądania oczekiwały na wolny proces PHP? Proszę również podać wykorzystanie CPU, PMEM, NPROC i EP w tym samym okresie. Jeżeli wyższy pakiet zwiększa workers, proszę wskazać, z jakiej wartości do jakiej i czy równocześnie zmienia pozostałe limity.
Takie pytanie pozwala rozdzielić reklamową liczbę w tabeli od rzeczywistej konfiguracji. Jeśli operator nie potrafi wskazać sposobu liczenia ani wykorzystania workers, nie traktuj samej wartości jako wystarczającej diagnozy.
Ile PHP workers potrzebuje WordPress?
Nie ma jednej poprawnej liczby dla każdego WordPressa. Potrzeba zależy od równoczesnego ruchu dynamicznego oraz czasu, przez jaki pojedyncze żądania zajmują proces PHP. Ten sam WordPress po usprawnieniu wolnego zapytania może obsłużyć więcej ruchu przy tej samej liczbie workers.
Najbardziej praktyczne podejście to sprawdzić, czy w realnym okresie problemu występuje kolejka lub pełne wykorzystanie workers, a następnie zestawić to z CPU, pamięcią i czasem wykonania aplikacji. Jeśli workers są stale zajęte podczas normalnego ruchu, a pozostałe zasoby mają zapas, większa liczba może mieć techniczne uzasadnienie. Jeśli workers mają zapas, problem trzeba szukać gdzie indziej.
Jeżeli WordPress ogólnie działa wolno, zacznij od poradnika diagnostycznego WordPress: hosting czy strona?. Pakiety możesz później zestawić w porównywarce hostingu, a koszt przeprowadzki policzyć w kalkulatorze opłacalności zmiany.
Liczba PHP workers ma sens dopiero razem z czasem wykonywania żądań i pozostałymi limitami. „10 workers” jest użyteczną informacją dopiero wtedy, gdy wiadomo, jak operator ją definiuje, czy procesy są rzeczywiście zajęte w czasie problemu oraz czy CPU i pamięć pozwalają wykorzystać większą współbieżność.