Hosting ogranicza liczbę procesów PHP? To jeden z tych limitów, które potrafią zaskoczyć dokładnie wtedy, gdy serwis zaczyna żyć – rośnie ruch, wpada kampania, boty intensywnie skanują stronę… i nagle użytkownicy widzą błędy 503/508, a panel hostingu krzyczy o wyczerpanych zasobach. Dobra wiadomość: z tym da się sobie poradzić — zarówno szybkimi usprawnieniami, jak i głębszą optymalizacją oraz mądrą architekturą.

Gdy hosting ogranicza liczbę procesów PHP – co to w praktyce znaczy?

Limit procesów to limit równoległych „pracowników” obsługujących żądania; gdy się wyczerpie, kolejne użytkowania muszą czekać lub dostają błąd.

W środowiskach współdzielonych limit dotyczy zwykle jednoczesnych procesów/workerów PHP-FPM (czasem LSAPI w LiteSpeed) i bywa powiązany z CPU, RAM oraz I/O. Każdy proces to „slot” dla jednego żądania; jeśli skrypt działa długo, blokuje slot, więc następne żądania się kumulują. Kluczowe jest więc skrócenie czasu obsługi żądań i obniżenie ich liczby — tak, aby dostępne „sloty” wystarczały.

W CloudLinux (częsty na shared hostingu) limit procesów (EP/PM), CPU i RAM współgrają: naruszenie jednego z nich może spowodować ograniczenie całej aplikacji. Objawami są często błędy 508 Resource Limit Is Reached, 503 Service Unavailable, albo wyraźne spowolnienie.

Jak rozpoznać problem i jego skalę

Zacznij od danych: logi, wykresy i proste testy pomogą zrozumieć, co „zjada” procesy.

• Sprawdź w panelu hostingu statystyki użycia (EP/PM, CPU, I/O, pamięć).
• Przejrzyj logi błędów PHP oraz serwera (błędy 503/508, time‑outy, „server busy”).
• Jeśli możesz, włącz status PHP-FPM (pm.status_path) — pokaże aktualnych workerów i kolejkę.
• Porównaj piki ruchu (np. kampanie, aktualizacje lub crawling) z momentami awarii.
• Zbadaj czas odpowiedzi kluczowych podstron (PageSpeed, WebPageTest, k6, ab/wrk).
• W CMS (np. WordPress) użyj narzędzi jak Query Monitor, aby znaleźć wolne zapytania i ciężkie hooki.

Im dokładniejsza diagnoza, tym lepiej dobierzesz lekarstwo — czasem wystarczy wycięcie jednego „winnego” zapytania SQL lub wtyczki, by obciążenie spadło o połowę.

Szybkie działania, które odciążą serwer od ręki

Wprowadź te zmiany, by natychmiast zmniejszyć liczbę jednoczesnych żądań i czas ich obsługi.

• Włącz pełny cache strony (page cache). W WordPress użyj dobrego pluginu cache lub, na serwerach LiteSpeed, LSCache.
• Skorzystaj z CDN (np. Cloudflare) i ustaw agresywne cache dla statycznych zasobów. Edge caching potrafi znacząco odjąć ruch od PHP.
• Ogranicz crawlery: robots.txt, reguły WAF/Rate Limiting (Cloudflare). Wytnij agresywne boty i narzędzia scrapujące.
• Wyłącz pseudo‑cron uruchamiany przy wejściach (np. w WordPress ustaw DISABLE_WP_CRON i odpalaj cronem co 5–10 min).
• Zminimalizuj liczbę i wagę zapytań HTTP do zewnętrznych API — stosuj cache wyników i krótkie time‑outy.
• Odetnij najbardziej ciężkie dodatki/wtyczki, które generują wiele zapytań lub długie pętle.
• Zastosuj kompresję (gzip/Brotli) i długie nagłówki Cache‑Control dla statycznych plików.
• Zoptymalizuj obrazy (formaty WebP/AVIF, lazy‑load). Mniej danych = krótszy czas procesu.
• Zredukuj liczbę skryptów i styli łącząc/minifikując je, by mniej żądań trafiało do PHP.

WordPress: konkretne ustawienia, które robią różnicę

Połączenie page cache + obiektowy cache + ograniczenie „hałaśliwych” wtyczek to największy efekt.

• Stały cache obiektowy (Redis/Memcached), jeśli hosting na to pozwala.
• Page cache: pełne Buforowanie HTML, z regułami wykluczeń dla stron dynamicznych.
• Ogranicz Heartbeat API, kontroluj cron (prawdziwy cron zamiast uruchamianego przez ruch).
• Wyłącz lub zamień wtyczki: statystyki w panelu, ciężkie kreatory, automatyczne miniatury w locie.
• Profiluj Query Monitor: znajdź najwolniejsze zapytania SQL i przemyśl indeksy.
• Cloudflare APO dla WP (jeśli pasuje do scenariusza) może przenieść większość ruchu z dala od PHP.

Zmiana konfiguracji procesów PHP (jeśli masz wpływ)

Lepsze zarządzanie workerami PHP bywa kluczowe, ale dostępne opcje zależą od rodzaju hostingu.

• PHP-FPM: tryb pm = ondemand/dynamic. Ondemand zmniejsza liczbę bezczynnych procesów.
• pm.max_children: mniej children = mniejsze użycie RAM, ale mniejsza równoległość; więcej children = większa równoległość, ale ryzyko memory swap/ubicia przez limity.
• pm.max_requests: restart workerów co X żądań pomaga w „wyciekach” pamięci.
• Ogranicz rozszerzenia PHP, których nie używasz (mniej pamięci per proces).
• Włącz OPcache z rozsądnymi ustawieniami (memory_consumption, max_accelerated_files). OPcache to darmowy „turbo” dla większości aplikacji PHP.
• Na LiteSpeed (LSAPI) włącz plugin LSCache — to potrafi zredukować potrzebę wielu procesów dzięki serwowaniu cache bez angażowania PHP.

Jeśli na hostingu współdzielonym nie masz dostępu do tych ustawień, dopytaj support — czasem drobny „tweak” albo wyższy pakiet zrobi dużą różnicę.

Optymalizacja kodu i bazy danych

Szybszy kod = krótsze życie procesu = więcej wolnych slotów dla kolejnych użytkowników.

• Profiling (Tideways, Blackfire, Xdebug profiler na stagingu): znajdź gorące miejsca.
• Usprawnij zapytania SQL: indeksy, paginacja, unikanie N+1, cache wyników.
• Używaj mechanizmów TTL i invalidacji w cache zamiast każdorazowego liczenia wszystkiego od zera.
• Unikaj blokujących wywołań zewnętrznych (długie cURL) — dodaj krótki time‑out i cache.
• Zadbaj o autoloader (Composer optimize‑autoload), usuń zależności dev na produkcji.
• W długich pętlach przetwarzaj porcjami (batching), by nie blokować procesu przez wiele sekund.

Oddzielanie zadań w tle od żądań użytkowników

Niech przeliczanie czy importy nie dzieją się „w trakcie” wizyty użytkownika.

• Kolejkuj ciężkie operacje (maile masowe, generowanie PDF, importy) i uruchamiaj je cronaem lub workerem CLI.
• Jeśli nie możesz użyć stałych workerów (Supervisor), zastosuj cron uruchamiający skrypt co X minut i przetwarzający paczki.
• Używaj locków/kolejek, by uniknąć sytuacji, w której kilkanaście procesów robi to samo.
• Generuj statyczne wersje stron/podstron (pre‑rendering), a odświeżaj je po zmianach treści.

Warstwa frontowa i ochrona przed „szumem”

Mniej „śmieciowego” ruchu i lepsze serwowanie statyki znacząco odciąża PHP.

• CDN + WAF (np. Cloudflare) z regułami rate limiting na endpointy wrażliwe (logowanie, wyszukiwarka).
• Dobre cache‑control dla statyki: długie TTL i versioning plików.
• Blokady dla znanych agresywnych botów (User‑Agent, ASN, zachowanie).
• Przy kampaniach, gdy spodziewasz się skoków ruchu, przebuduj cache i seeduj go, aby „pierwsza fala” nie trafiła do PHP.

Kiedy prosić o zwiększenie limitu lub migrację

Czasem optymalizacja nie wystarczy — biznes rośnie i potrzebujesz więcej zasobów.

• Poproś support o wgląd w limity i ewentualne podniesienie (czasem to kwestia pakietu).
• Rozważ przejście na plan z LiteSpeed/LSCache lub na managed VPS, gdzie sam ustawisz PHP-FPM.
• Przy intensywnych projektach rozdzielaj warstwy: osobny serwer dla bazy, CDN na froncie, worker do kolejek.
• Jeżeli aplikacja wymaga stałej wysokiej równoległości, VPS/Kubernetes lub serwer dedykowany to naturalny krok.

Check‑lista działań krok po kroku

Prosty plan, który wdrożysz w jeden-dwa dni.

1. Włącz page cache i CDN, ustaw długie cache dla statyki.
2. Ogranicz boty i ustaw rate limiting dla wrażliwych endpointów.
3. Wyłącz wp‑cron przy wejściu, uruchamiaj prawdziwy cron.
4. Zidentyfikuj i usuń 1–2 najbardziej obciążające wtyczki/funkcje.
5. Wdróż OPcache i usuń nieużywane rozszerzenia PHP.
6. Włącz cache obiektowy (Redis/Memcached), jeśli możliwe.
7. Zoptymalizuj 2–3 najwolniejsze zapytania SQL (indeksy!).
8. Przenieś ciężkie zadania do kolejek/cron, zrób batching.
9. Monitoruj: logi błędów, metryki z panelu hostingu, czas odpowiedzi.
10. Porozmawiaj z supportem o limitach lub migracji, jeśli wciąż dociskasz sufit.

Najczęstsze błędy, które pogłębiają problem

Unikaj tych pułapek — to szybka droga do zapchania procesów.

• Brak pełnego cache i brak CDN przy rosnącym ruchu.
• „Ciężkie” zapytania bez indeksów, odpalane przy każdym wejściu.
• Wielokrotne wywołania zewnętrznych API bez cache i z długimi time‑outami.
• Przetwarzanie masowych zadań podczas żądań użytkownika.
• Zbyt wiele wtyczek „od wszystkiego”, które nakładają swoje hooki i cron‑y.
• Ignorowanie botów i crawlers — potrafią zająć większość slotów procesów.

Podsumowanie i kierunek na przyszłość

Celem jest mniejsze zapotrzebowanie na równoległe procesy i krótszy czas życia każdego z nich.

Najpierw „odetnij tlen” problemowi: pełny cache, CDN, blokada botów, OPcache i podstawowe porządki w wtyczkach/kodzie. Potem zoptymalizuj bazę i zewnętrzne wywołania, a ciężkie zadania przenieś poza ścieżkę żądania użytkownika. Jeżeli mimo tego wciąż dobijasz do sufitu, negocjuj wyższe limity lub przenieś się na plan, który daje kontrolę nad PHP‑FPM i zasobami.

Gdy hosting ogranicza liczbę procesów PHP, wygrywa nie ten, kto ma najwięcej „slotów”, ale ten, kto najlepiej je wykorzystuje: serwuje z cache, szybko liczy to, co musi, i nie marnuje cykli na to, co można zrobić gdzie indziej lub wcześniej. Dzięki tym zasadom zarówno małe, jak i rosnące projekty poradzą sobie z ograniczeniami bez utraty jakości doświadczenia użytkownika.