Porównanie trybów PHP-FPM: Statyczny, Dynamiczny i Ondemand

Ten artykuł porównuje tryby PHP-FPM statyczny, dynamiczny oraz na żądanie i pokazuje, w jaki sposób uruchamiają procesy, wiążą pamięć RAM i wpływają na opóźnienia. Wyjaśniam w praktyczny sposób, kiedy który tryb jest przekonujący, podaję rozsądne wartości początkowe, wymieniam typowe przeszkody i pokazuję sztuczki monitorujące, abyś mógł zoptymalizować swoje procesy. PHP-bezpieczne baseny.

Punkty centralne

Aby pomóc ci szybko zacząć, podsumuję najważniejsze stwierdzenia w kompaktowym formacie. Skupiamy się na kontroli procesu, wymaganiach dotyczących pamięci RAM, opóźnieniach i obszarach zastosowań. Każdy wybór ma wyraźne mocne strony, ale także ograniczenia. Dzięki kilku kluczowym liczbom można podejmować wiarygodne decyzje. Można więc przyjąć ukierunkowane podejście Strojenie i zaoszczędzić czas.

• StatycznyStały numer procesu, maksymalna spójność przy stałym obciążeniu.
• DynamicznyAutomatyczne skalowanie między wartościami minimalnymi i maksymalnymi.
• OndemandUruchamianie na żądanie, ekonomiczna praca na biegu jałowym, opóźnienie zimnego rozruchu.
• Planowanie pamięci RAMZezwalaj na 20-50 MB na proces, unikaj OOM.
• MonitoringStrona stanu, dzienniki i htop dla uzasadnionych decyzji.

Jak działa Menedżer procesów

Menedżer procesów PHP-FPM kontroluje liczbę Pracownik-przetwarza żądania przetwarzania i kiedy się one rozpoczynają lub kończą. Każda instancja robocza przechowuje interpretery, rozszerzenia i części kodu bajtowego w pamięci, co zwykle oznacza kilka Megabajt binds. Trzy tryby znacząco zmieniają zachowanie podczas uruchamiania, cykl życia i zachowanie w stanie bezczynności. Statyczny utrzymuje stałą liczbę aktywnych procesów, dynamiczny balansuje między dolnym i górnym limitem, a Ondemand tworzy procesy tylko wtedy, gdy otrzymywane są żądania. Kontrola ta ma bezpośredni wpływ na RAM-profil, opóźnienia podczas włączania i szczyty obciążenia systemu.

Ważne parametry stanowią podstawę konfiguracji: pm określa tryb, pm.max_children ograniczona liczba jednoczesnych pracowników. Dzięki Dynamic pm.start_servers, pm.min_spare_servers oraz pm.max_spare_servers które kontrolują szerokość bufora. Ondemand polega na pm.process_idle_timeout, aby ponownie zakończyć uśpione procesy. Rozsądne wartości zapewniają, że szczyty obciążenia nie prowadzą do wąskich gardeł, a maszyna nie znajduje się pod presją pamięci.

Sprawdzam ślad na proces, średnie jednoczesne obciążenie i rozkład szczytów w ciągu dnia z wyprzedzeniem. Z tych zmiennych wyprowadzam maksymalną wartość dla pm.max_children pomnożyć przez zmierzoną pamięć procesu i pozostawić rezerwę dla serwera WWW, bazy danych, pamięci podręcznej i jądra. To proste obliczenie zapobiega błędom braku pamięci i zapewnia Stabilność pod presją. Jeśli weźmiesz to sobie do serca, zaoszczędzisz sobie kłopotów z późniejszym dostosowywaniem.

Tryb statyczny: stała moc dla równomiernego obciążenia

Tryb statyczny utrzymuje stałą liczbę aktywnych pracowników PHP, co Start-Koszty ogólne zostały wyeliminowane. Przy stałych profilach ruchu, ta konfiguracja osiąga bardzo niskie wahania opóźnień i równomierne obciążenie. CPU-obciążenie. Wada: W stanie bezczynności pamięć RAM pozostaje zajęta, nawet jeśli nie ma żadnych żądań. Dlatego wybieram Static tylko na hostach z dużą ilością pamięci RAM i obliczalnym wolumenem żądań. W przypadku często używanych sklepów lub backendów API, Static często zapewnia najczystszą krzywą odpowiedzi.

Decydującym czynnikiem jest realistyczna konfiguracja pm.max_children, który jest oparty na śladzie procesu. W przypadku pierwszego oszacowania, z grubsza obliczam 20-50 MB na proces PHP, w tym rozszerzenia i OPcache. Ostateczną wartość weryfikuję za pomocą testów obciążenia i monitora systemu. Jeśli chcesz pogłębić obliczenia, możesz znaleźć praktyczne kroki na stronie Optymalizacja pm.max_children. Zapewnia to, że stały rozmiar puli pasuje do sprzętu.

[www]
pm = static
pm.max_children = 50
pm.max_requests = 500

WskazówkaPo zmianach restartuję PHP-FPM, sprawdzam logi i obserwuję wykorzystanie w rzeczywistym ruchu. Jeśli nadal jest dużo wolnej pamięci RAM, ostrożnie ją zwiększam. Jeśli widzę rosnące wykorzystanie swapów lub wpisy OOM killer, natychmiast je zmniejszam. Ta mała procedura chroni Dostępność niezawodny.

Tryb dynamiczny: elastyczność przy zmiennym zapotrzebowaniu

Dynamic zaczyna od zaledwie kilku procesów i skaluje Pracownik-numer w określonym zakresie zgodnie z wymaganiami. Zmniejsza to zużycie bezczynności podczas cichych faz, podczas gdy krótkie szczyty są amortyzowane. Metoda generuje pewien narzut podczas odradzania, ale zdobywa punkty dzięki dobrym Zasoby-Wydajność. W mieszanych środowiskach z codziennymi profilami, Dynamic często zapewnia najlepszy kompromis. Tryb ten pozostaje pierwszym wyborem w szczególności dla wielu instalacji CMS.

Ustawiłem wartości początkowe, minimalne i maksymalne tak, aby przy typowym obciążeniu nie występowały stałe zdarzenia odradzania. Częste komunikaty dziennika, takie jak „wydaje się zajęty, odradza dzieci“ wskazują, że limity są zbyt wąskie. W przypadku stosów WordPress pomaga prawidłowe ustawienie buforowania i OPcache, a następnie umiarkowane ich zwiększanie. Kompaktowy przewodnik obejmuje najważniejsze dźwignie: Zoptymalizowane ustawienia WordPress. Pozwala to na osiągnięcie krótkich czasów reakcji bez RAM-rezerwa.

[www]
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

WskazówkaObserwuj bezczynnych pracowników i średnią liczbę aktywnych procesów w ciągu dnia. Jeśli średnia wartość jest bliska górnej granicy, należy ją umiarkowanie zwiększyć. Jeśli wiele procesów pozostaje bezczynnych, obniż zakres. Wystarczy kilka iteracji, aby osiągnąć wartość Słodkie miejsce-ustawienie.

Tryb Ondemand: ekonomiczny w trybie bezczynności, uruchamianie na żądanie

Ondemand tworzy procesy tylko wtedy, gdy Zapytanie i kończy ją po upływie czasu bezczynności. Zmniejsza to zapotrzebowanie na pamięć RAM do minimum w fazach bezczynności, co sprzyja wielu małym witrynom na jednej maszynie. Podczas zimnych startów występują jednak dodatkowe opóźnienia, ponieważ worker najpierw się uruchamia i rozgrzewa. W przypadku środowisk programistycznych, aplikacji korzystających wyłącznie z cronów i rzadko odwiedzanych witryn, logika ta jest Zysk. Nie używałbym Ondemand pod ciągłym obciążeniem.

[www]
pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 10s
pm.max_requests = 500

Zwykle ustawiam czas bezczynności na 10 do 30 sekund, w zależności od wzorca połączeń i budżetu pamięci. Krótszy czas oszczędza RAM, ale zwiększa ryzyko zimnego startu. Dłuższy okres utrzymuje procesy w cieple, ale kosztuje pamięć. Dlatego monitoruję częstotliwość wywołań, mierzę 95. percentyl opóźnienia, a następnie dokonuję drobnych korekt. Pozwala to utrzymać Czas reakcji obliczalne bez obciążania systemu.

Tabela porównawcza: Właściwości trzech trybów

Poniższy przegląd porównuje typowe właściwości. Używam go jako podstawy do dyskusji przed przejściem do konkretnych rozmiarów. Tabela nie zastępuje pomiaru pod rzeczywistym obciążeniem, ale zapewnia uporządkowany przegląd. Punkt początkowy. Jeśli dostosujesz wartości, zawsze powinieneś mieć oko na profil pamięci i rozkład opóźnień. Pozostań więc przy Szczyty i uniknąć wąskich gardeł.

Kryterium	Statyczny	Dynamiczny	Ondemand
Procesy	Stały numer, stale aktywny	Automatycznie między min/max	Uruchamianie tylko wtedy, gdy jest to wymagane
Wykorzystanie pamięci RAM	Stale wysoki poziom	Zmienna (np. 200-600 MB)	Minimum w trybie bezczynności (np. 50-700 MB)
Wydajność	Bardzo równy	Dobry i elastyczny	Dobry dla małego ruchu
Idealny dla	Stałe profile o dużym natężeniu ruchu	Zmienny popyt	Wiele nieaktywnych witryn / Udostępnione
Nad głową	Niski	Średni (odrodzenie/odpalenie)	Wyższa dla zimnych startów

Tabela pomaga skalibrować oczekiwania i jasno określić priorytety. Jeśli potrzebujesz maksymalnej spójności odpowiedzi, zwycięzcą jest często Statyczny. Liczy wydajność przy zmiennym obciążeniu, działa Dynamiczny zwykle przyjemniejsze. Jeśli oszczędność jest priorytetem, nie ma możliwości jej obejścia. Ondemand nad. Ostatecznie decydują zmierzone wartości, a nie założenia.

Obliczanie i określanie rozmiaru zasobów

Najpierw szacuję ilość pamięci na Proces Pomnóż to przez planowaną liczbę pracowników i dodaj 20-30 % rezerwy. Uwzględniam również miejsce na Nginx/Apache, bazę danych, Redis/Memcached i jądro. Suma ta nie może przekroczyć fizycznej pojemności pamięci RAM pomniejszonej o margines bezpieczeństwa. Planuję dedykowaną pamięć dla OPcache, aby kod bajtowy nie został przesunięty. Z tym prostym Formuła Uważam, że ryzyko OOM jest niskie.

W następnym kroku mierzę jednoczesne żądania za pomocą stanu serwera WWW i APM. Szczytowa konkurencja dla pracowników PHP określa, jak wysoki pm.max_children musi być. Jeśli pamięć RAM nie jest wystarczająca, zwiększam liczbę trafień w pamięci podręcznej, skracam czasy zapytań lub przenoszę pracę do kolejek. Dopiero gdy te dźwignie zaczną działać, zwiększam pulę. Pozwala to utrzymać Wydajność wysoka, a urządzenie reaguje niezawodnie.

Monitorowanie i rozwiązywanie problemów

Dobre decyzje opierają się na Dane. Aktywuję stronę statusu PHP-FPM i odczytuję aktywne i bezczynne procesy, długość kolejki i zaakceptowane połączenia. Sprawdzam również dzienniki błędów pod kątem ostrzeżeń o odrodzeniu i limitów czasu. W htop monitoruję czas oczekiwania procesora, obciążenie i swap, aby szybciej znaleźć wąskie gardła. Sygnały te sprawiają, że kroki strojenia zrozumiały i uniknąć latania na ślepo.

<?php
$status = @file_get_contents('http://localhost/status');
$data = json_decode($status, true);
echo "Active: " . $data['active processes'] . "\n";
echo "Idle: " . $data['idle processes'] . "\n";
?>

Narzędzia APM pokazują ślady i wąskie gardła na poziomie funkcji lub zapytań. Jeśli znajdę tam wartości odstające, najpierw zaczynam od buforowania i operacji we/wy. Następnie sprawdzam, czy limity puli odpowiadają rzeczywistej równoległości. Dopiero gdy wąskie gardła aplikacji zostaną rozwiązane, warto zrobić więcej Pojemność w FPM. Proces ten oszczędza czas i utrzymuje architekturę na niskim poziomie.

Unikanie typowych błędów strojenia

Często widzę zbyt wysokie max_children-wartości niezależnie od pamięci RAM. Powoduje to niepotrzebną wymianę, długie fazy zbierania śmieci i ostatecznie zabójców OOM. Zbyt niskie limity są również szkodliwe, ponieważ tworzą kolejki i wydłużają czas odpowiedzi. Brak OPcache również marnuje czas procesora i zwiększa ślad procesu. Z kilkoma Czeki Pułapki te są z góry zabezpieczone.

Drugi klasyk: nieodpowiednie limity czasowe w Ondemand, które prowadzą do wielu zimnych startów. Krótki test A/B z 10, 20 i 30 sekundami bezczynności pomaga tutaj. Z kolei w przypadku Dynamic zbyt małe wartości zapasowe powodują ciągłe odradzanie się. Logi szybko ujawniają te wzorce i kierują następnymi krokami. Personalizacja on. Dzięki temu stos jest responsywny.

PHP-FPM w kontekście innych programów obsługi PHP

PHP-FPM jest często porównywany do starych wariantów CGI lub nowoczesnych alternatyw, takich jak LSAPI. Wybór programu obsługi wpływa na zarządzanie procesem, Zasoby-charakterystyka i izolacja błędów. Zrozumienie tych różnic pozwala na bardziej realistyczne planowanie buforów i limitów. Aby uzyskać szybki przegląd, warto poświęcić chwilę na Porównanie obsługi PHP. Następnie decyzja na korzyść trybów FPM jest wyraźnie bardziej ukierunkowane od.

Zwykle trzymam się FPM, ponieważ jest dojrzały, czysto loguje i dobrze współpracuje z Nginx/Apache. Decydujące są nie tylko benchmarki, ale także aspekty operacyjne, takie jak obserwowalność i przełączanie awaryjne. Jeśli te podstawy są prawidłowe, uzyskasz więcej ze Static, Dynamic lub Ondemand. Każda opcja zasługuje na przetestowanie pod rzeczywistym obciążeniem. W ten sposób można zyskać zaufanie do Ustawienia.

Praktyczna strategia podejmowania decyzji

Zaczynam od Dynamic jako Domyślne, Mierzę profile obciążenia i obserwuję szczyty. Jeśli stwierdzam bardzo stałe wykorzystanie, przełączam się na Static i ustawiam stały rozmiar puli. Jeśli napotykam rzadko używane witryny, wybieram Ondemand z odpowiednim limitem czasu bezczynności. Jednocześnie optymalizuję OPcache, cache obiektów i zapytania do bazy danych, aby FPM był pod mniejszą presją. Następnie dostosowuję limity tak, aby Kolejki w ogóle nie powstały.

Taka kolejność zmniejsza ryzyko i nakład pracy. Najpierw pomiar, potem dostosowanie zasad, a następnie rozważenie sprzętu. Każdą zmianę krótko dokumentuję, podając czas, wartości i cel. Ułatwia to późniejsze wprowadzanie poprawek i zapewnia czystość. Przejrzystość. Pozwala to na zarządzanie stosem, nawet w przypadku zmiany wzorców ruchu.

Od kluczowych liczb do wiarygodnych wartości: oto jak obliczam

Przekładam profile obciążenia na konkretne rozmiary puli, korzystając z prostej zasady: ile żądań przychodzi na sekundę i ile czasu zajmuje ich przetworzenie średnio lub przy 95. percentylu? Jako przewodnika używam następujących danych Prawo Little'a w prostej formie: jednoczesne przetwarzanie ≈ przepustowość × średni czas przetwarzania. Przykład: 120 żądań/s przy średnim czasie przetwarzania 80 ms daje około 9,6 jednoczesnych wykonań. Dodaję 30-50 buforów % dla szczytów i sprawdzam, czy wynikowy pm.max_children mieszczą się w moim budżecie pamięci RAM. W przypadku wysokich szczytów uwzględniam również 95. percentyl, aby uniknąć kolejek.

Ważne jest, aby Charakter obciążenia: W przypadku aplikacji o dużym obciążeniu we/wy (wiele zdalnych wywołań, dostęp do bazy danych), nieco większa liczba pracowników często przynosi korzyści, ponieważ czasy oczekiwania nakładają się na siebie. W przypadku kodu o dużym obciążeniu procesora, ograniczam więcej, aby procesy nie spowalniały się nawzajem, a kolejka uruchamiania nie eksplodowała.

pm.max_requests: czysty recykling przed fragmentacją

Długo działające procesy PHP mogą zostać zatrzymane przez Fragmentacja lub wycieków pamięci. Z pm.max_requests definiuje, po ilu przetworzonych żądaniach worker zostanie zakończony i uruchomiony ponownie. Utrzymuje to stabilny ślad. Zwykle zaczynam od 300-1000, w zależności od rozszerzeń i bazy kodu. Obserwuj wartości RSS/PSS procesów: Jeśli znacznie wzrosną, zmniejsz wartość. Ponieważ OPcache udostępniony Kod bajtowy jest zachowywany podczas recyklingu pracowników; dlatego większość aplikacji prawie nie zauważa recyklingu.

[www]
ukierunkowany recykling bez zbyt częstych restartów
pm.max_requests = 800

Każdy, kto regularnie Wdrożenia korzyści z przeładowania puli. Wolę używać elegantne ponowne ładowanie za pośrednictwem menedżera usług (np. „systemctl reload php-fpm“), tak aby uruchomione żądania kończyły się czysto, a nowi pracownicy uruchamiali się ze zaktualizowaną konfiguracją.

Slowlog i timeouty: wizualizacja wąskich gardeł w ukierunkowany sposób

Większość szczytów opóźnień jest spowodowana kilkoma wolnymi żądaniami. Dlatego aktywuję funkcję Slowlog z umiarkowaną wartością progową (np. 2-5 s) i przyjrzeć się śladom stosu. W ten sposób znajduję problematyczne funkcje, zewnętrzne wywołania lub kosztowne zapytania.

[www]
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/slowlog-www.log

Zgodnie z tym, dopasowuję Limity czasu serwera WWW. Upstream timeout (Nginx/Apache), który jest zbyt krótki w porównaniu do PHP max_execution_time prowadzi do błędów 502/504, chociaż FPM nadal działa. Utrzymuję spójny łańcuch: łączenie, odczytywanie i wysyłanie limitów czasu serwera WWW nieco powyżej typowego czasu trwania żądania PHP, ale poniżej twardych górnych limitów.

Prawidłowa interpretacja wartości kolejki, zaległości i statusu

W statusie FPM zwracam szczególną uwagę na „kolejka odsłuchu“ i „maksymalna kolejka nasłuchiwania“. Jeśli wartości te regularnie rosną, oznacza to, że pula jest zbyt mała lub zablokowana. Krótkotrwałe szczyty są normalne, ale stałe zatory wskazują na zbyt mały rozmiar. W środowiskach o dużym natężeniu ruchu zwiększam gniazdozaległości umiarkowanie, obserwuj kolejkę i upewnij się, że limity jądra (np. somaxconn) nie są wąskim gardłem.

Jeśli monitorowanie pokazuje bardzo często „wydaje się zajęty, odradza dzieci“, parametry rezerwy (dynamiczne) są zbyt wąskie. W przypadku Ondemand, powtarzający się wysoki odsetek zimnych startów jest wskazaniem do wydłużenia czasu bezczynności lub utrzymania minimalnego bufora w ciągu dnia.

Wiele pul: Sprawiedliwość, izolacja i kwoty

W przypadku wielu dzierżawców lub Współdzielony-hostów, rozdzielam aplikacje na ich własne pule z indywidualnymi limitami. Zapobiega to wypieraniu innych przez projekty wymagające dużej ilości pamięci. Dla krytycznych usług (np. punktów końcowych logowania/API) planuję dedykowane pule ze stałą minimalną rezerwą. Jasne nazewnictwo („www-shop“, „www-api“, „www-cron“) i oddzielne logi ułatwiają analizę i zarządzanie danymi. Błądwyszukiwanie.

Upewnij się, że suma wszystkich pm.max_children pasuje do maszyny we wszystkich basenach. Kupuję również Limity w dół rzeki na: DB-.max_connections, Wątkowanie Redis/Memcached i zewnętrzne stawki API. Pula PHP, która odpala więcej jednoczesnych zapytań niż baza danych może obsłużyć, kupuje sobie tylko dłuższe kolejki.

Rozgrzewka, wstępne ładowanie i zimny rozruch OPcache w ryzach

Do Ondemand-Aby złagodzić zimne starty, utrzymuję stabilny OPcache (wystarczający zużycie pamięci oraz interned_strings_buffer) i, w razie potrzeby, ustawić na Obciążenie wstępne centralne klasy/frameworki. Oznacza to, że kod bajtowy jest dostępny po pierwszym trafieniu, a powtórzenia pozostają ciepłe. Ponadto większa pamięć podręczna ścieżki rzeczywistej i ustrukturyzowany autoloader pomagają zmniejszyć liczbę wyszukiwań w systemie plików. Podsumowując, znacznie skraca to czas uruchamiania świeżo uruchomionych pracowników.

Interakcja z serwerem WWW: czyste połączenie Nginx/Apache

Upewniam się, że ustawienia serwera WWW i FPM są zgodne: Bufor i Limity czasu muszą być symetryczne, keep-alive nie może blokować FPM połączeniami zombie, a gniazdo upstream (Unix lub TCP) musi być spójnie skonfigurowane. Wiele błędów 502/504 jest spowodowanych nieprawidłowo ustawionymi limitami czasu odczytu lub wyczerpanymi zaległościami. Każdy, kto adresuje FPM przez TCP, powinien wziąć pod uwagę opóźnienia stosu sieciowego i ryzyko półotwarty Miej oko na połączenia; zwykle preferuję gniazda uniksowe do wdrożeń lokalnych.

Cechy szczególne kontenera/VM

W kontenerach cgroup-limity, niekoniecznie wartości hosta. Wymiaruję pule wyraźnie dla pamięci RAM kontenera i używam sztucznych szczytów obciążenia, aby sprawdzić, czy zabójcy OOM mogą zadziałać. Zbyt wąski limit prowadzi do trudnych anulowań. Zamiana w kontenerach jest również często niepożądana - więc lepiej być nieco bardziej konserwatywnym z pm.max_children planować i ustalać priorytety buforowania aplikacji.

Rozpoznawanie znaków procesora i wejścia/wyjścia

Używam htop/iostat do oceny, czy obciążenia są CPU- lub są związane z wejściami/wyjściami. Wysokie wykorzystanie CPU przy niskim czasie oczekiwania I/O wskazuje na obciążenie obliczeniowe - tutaj ograniczam liczbę pracowników do liczby rdzeni. Wysokie oczekiwania I/O uzasadniają większą liczbę pracowników, ponieważ czasy oczekiwania w bazie danych, sieci lub systemie plików nakładają się na siebie. Limit można rozpoznać po tym, że opóźnienie nie zmniejsza się już pomimo dodatkowych pracowników, ale obciążenie znacznie wzrasta.

Szybkie dekodowanie typowych wzorców 502/504

• 504 Limit czasu bramy: Limit czasu serwera WWW krótszy niż czas wykonania PHP lub zablokowana pula (kolejka pełna).
• 502 Zła brama: FPM nieosiągalny (gniazdo/port), awaria/restart podczas żądania lub zbyt mały bufor.
• Skoki wkrótce po wdrożeniu: OPcache na zimno, sprawdź optymalizacje autoloadera/kompozytora, zaplanuj rozgrzewkę.

Koreluję dziennik błędów serwera WWW, dziennik błędów FPM i stronę stanu w tym samym oknie czasowym. To pokazuje, czy problem wystąpił przed, w lub do FPM jest zlokalizowany.

Pomiar handlu: Prawidłowe rejestrowanie kosztów magazynowania

W przypadku planowania pamięci RAM nie patrzę tylko na RSS, ale także na PSS (Proportional Set Size), ponieważ sprawiedliwie rozkłada podzielone strony (np. OPcache) na procesy. Narzędzia takie jak smem lub pmap pomagają określić realistyczne wartości związane z procesem. W praktyce jednak losowe próbki pod obciążeniem są często wystarczające: zaznacz kilka procesów, oblicz średnią, porównaj z Rezerwa pomnożyć - to lepiej odzwierciedla rzeczywistość niż teoretyczne wartości z forów.

Mini lista kontrolna do szybkich iteracji

• Zapis profilu obciążenia (RPS, 50/95/99 percentyl, równoległość).
• Mierzenie śladu procesu (PSS, nie tylko RSS) i pm.max_children z rezerwą.
• Wybierz tryb pasujący do wzorca: Statyczny (stały), Dynamiczny (zmieniający się), Ondemand (dużo czasu bezczynności).
• pm.max_requests ustawić, obserwować wzrost pracowników, w razie potrzeby ponownie wyregulować.
• Wymiar OPcache i sprawdzenie rozgrzewki/przeładowania w celu ograniczenia zimnych startów.
• Aktywuj stronę stanu i slowlog, analizuj kolejkę i odradzaj wiadomości.
• Synchronizacja limitów czasu serwera WWW i buforów z FPM i czasami aplikacji.
• Harmonizacja limitów z systemami niższego szczebla (DB, cache, zewnętrzne API).
• Dokumentowanie zmian, pomiary i iteracja po wdrożeniach.

Kompaktowe podsumowanie

Statyczny zapewnia najbardziej płynny czas reakcji i nadaje się do ciągłego ruchu z dużą ilością pamięci RAM. Dynamiczny Równoważy elastyczność i wydajność oraz osiąga wysokie wyniki przy zmieniających się wzorcach. Ondemand oszczędza pamięć w stanie bezczynności i jest odpowiednia dla wielu uśpionych witryn, ale wiąże się z opóźnieniem zimnego startu. Dzięki czystemu obliczaniu zasobów, monitorowaniu i małym iteracjom można podejmować wiarygodne decyzje. Utrzymuj procesy tak małe, jak to konieczne, korzystaj z OPcache i wybierz tryb, który odpowiada Twoim rzeczywistym potrzebom. Profil pasuje.

Dzięki tym poręczom można osiągnąć stabilną wydajność przy rozsądnym zużyciu energii. Konfiguracja to nie zgadywanka, gdy na stole leżą liczby. Małe kroki często przynoszą największe efekty. Mierz, dostosowuj i dokumentuj. Tak więc PHP-FPM-szybko, ekonomicznie i przewidywalnie.