Slovník pojmů

PHP-FPM

PHP-FPM drží PHP procesy pro dynamické requesty za nginxem a jeho FastCGI požadavky.

Stručná definice

Správce PHP workerů mezi webovým serverem a aplikačním kódem.

PHP-FPM je hlavní implementace PHP pro FastCGI provoz. Webový server předá informace o skriptu, URI, metodě, hlavičkách a těle požadavku. Dostupný worker inicializuje PHP, zavolá aplikaci a vrátí výstup přes FastCGI. Po dokončení obslouží další request, případně jej správce po určeném počtu požadavků nahradí.

PHP-FPM není webový server ani fronta pro dlouhou práci. Na Linuxu spravuje PHP workery, ale neřeší TLS, veřejné porty ani load balancing HTTP klientů. Proto se obvykle kombinuje s nginxem, případně běží jako interní služba v Docker síti.

K čemu se používá

Spouštění PHP webů, API a administrací pod řízenými limity

FPM je určené pro PHP aplikace, které dostávají HTTP požadavky od samostatného webového serveru.

Symfony, Laravel nebo vlastní PHP aplikace obsluhované přes nginx a FastCGI
více poolů s odlišným uživatelem, php.ini, limity nebo socketem pro oddělené aplikace
omezení souběžných PHP requestů podle dostupné paměti a výkonu serveru
diagnostika pomalých requestů pomocí slowlogu, status stránky a standardních logů
opakovatelný PHP runtime v kontejneru, kde webový server komunikuje s aplikací přes interní síť

Praktický příklad

Symfony API za nginxem a odděleným FPM poolem

nginx přijímá HTTPS a posílá pouze front controller Symfony aplikace na interní FPM socket. Pool má omezený počet dynamických workerů, slowlog a pravidelnou obnovu po určitém počtu requestů. Databáze ani FPM socket nejsou přístupné z veřejné sítě. Endpoint exportu objednávek místo dlouhého requestu vytvoří úlohu pro worker.

Hodnoty jsou příklad, nikoli univerzální doporučení. max_children se určuje z paměti procesu, souběhu databáze a cílové doby odpovědi. Status cesta má být pouze v interní síti.

; www.conf
[www]
listen = /run/php/php-fpm.sock
pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log

Jak funguje

Od HTTP requestu k PHP workeru a zpět

Každá část cesty má vlastní limit a log, takže lze určit zdroj problému.

nginx přijme HTTP nginx ukončí TLS, vybere server a location a statické soubory může vrátit bez PHP. Jen dynamická cesta se předává přes fastcgi_pass.
FastCGI parametry Webový server předá metodu, URI, query string, hlavičky a cestu ke skriptu. Špatně nastavený SCRIPT_FILENAME nebo příliš obecné PHP location může být funkční i bezpečnostní problém.
Pool vybere worker Pool poslouchá na Unix socketu nebo TCP portu. Dostupný child process zpracuje požadavek; pokud všichni pracují, request čeká nebo narazí na limit podle okolní konfigurace.
Aplikace vykoná práci PHP načte Composer autoloader, framework a aplikační službu. Pomalý SQL dotaz, vzdálené API nebo velký import drží worker po celou dobu obsazený.
Odpověď a obnova procesu FPM vrátí odpověď nginxu a worker zůstane pro další request. pm.max_requests může worker pravidelně nahradit, aby se omezil dopad postupně rostoucí spotřeby paměti.

Hlavní části

Pool, procesní režim a limity musí odpovídat skutečnému zatížení.

Nastavení vychází z paměti, doby requestu a počtu souběžných služeb.

Pool

Pool je skupina workerů s vlastním listen socketem, uživatelem, prostředím a částí konfigurace. Umožní oddělit aplikace nebo citlivější administraci, ale příliš mnoho poolů zvyšuje režii a složitost.

static, dynamic a ondemand

Režim static drží pevný počet workerů. dynamic spravuje minimální a maximální počet podle zatížení. ondemand vytváří child procesy až při požadavku a po nečinnosti je ukončí; šetří paměť, ale může přidat startovní zpoždění.

pm.max_children

Maximální počet souběžných PHP requestů chrání server před nekontrolovaným vytvářením procesů. Jeho hodnota vychází z reálné paměti jednoho workeru, rezervy pro databázi a systém, ne z počtu CPU jako jednoduchého pravidla.

Socket nebo TCP

Unix socket je běžný při společném hostiteli; TCP se používá při oddělených kontejnerech nebo serverech. V obou případech musí být endpoint neveřejný a přístup omezený na webový server.

Status, slowlog a restart

FPM umí poskytovat stav poolu, logovat neobvykle dlouhé skripty a graceful restartovat workery. Tyto údaje jsou diagnostika; nenahrazují aplikační metriky, tracing ani opravu pomalého kódu.

Výhody a omezení

Připravené workery snižují startovní režii, ale každý zabírá paměť.

Přínosy

samostatný procesní model PHP oddělený od HTTP a statických souborů
pooly umožní nastavit limity a oprávnění pro různé aplikace
řízení child procesů, graceful restart, slowlog a status usnadňují provozní diagnostiku
spolupráce s nginxem dovolí obsloužit mnoho běžných webových requestů bez vytváření nového PHP procesu

Rizika a chyby

příliš vysoké pm.max_children může vyčerpat paměť a způsobit OOM místo vyššího výkonu
pomalé externí volání nebo export obsadí worker a sníží kapacitu celého webu
veřejně otevřený FPM TCP port dovoluje nechtěný přístup k runtime
špatný FastCGI parametr může spustit nesprávný skript nebo rozbít routování
zvýšení počtu workerů nevyřeší chybějící databázový index, zámek ani pomalou integraci

Hranice použití

Webový pool chránit před dlouhou a dávkovou prací.

PHP-FPM je přiměřená volba pro HTTP requesty s jasným timeoutem a omezenou pamětí. Kapacita vychází z reálné velikosti workeru a rezervy pro systém, databázi i cache. Krátký endpoint může potřebovat jinou politiku než administrativní export.

Dlouhé importy, přepočty katalogu, generování souborů a retry externích API nemají držet webový FPM worker. Fronta nebo CLI worker dá úloze vlastní limit, retry a monitoring. fastcgi_finish_request může ukončit odpověď klientovi dříve, ale neudělá z dlouhé práce nezávislý worker.

Na co myslet

Limity nastavovat podle měření, ne podle univerzálního čísla z návodu.

Provoz sleduje čekající requesty, délku skriptů, paměť a chyby nginxu, FPM i aplikace.

počítat pm.max_children z reálné paměti workerů a ponechat rezervu pro celý hostitel či kontejner
oddělit veřejný HTTP server od neveřejného FPM socketu nebo TCP portu
nastavit fastcgi parametry tak, aby aplikace dostala správnou cestu, schéma a očekávané hlavičky
použít slowlog a status endpoint chráněný před veřejným přístupem pro hledání blokujících requestů
synchronizovat timeouty nginxu, FPM a aplikace podle typu endpointu místo bezdůvodného zvyšování všech limitů
po deployi provést graceful reload a ověřit health check, chyby a spotřebu paměti nových workerů

Časté otázky

Jak PHP-FPM ovlivňuje běh webu

Je PHP-FPM webový server?

Ne. Zpracovává PHP přes FastCGI. HTTP, TLS, statické soubory a veřejnou síťovou hranici obvykle řeší nginx nebo jiný webový server před ním.

Zvýší více workerů vždy výkon?

Ne. Více workerů zvyšuje souběh, ale spotřebuje paměť a může zvýšit tlak na databázi či externí API. Po překročení kapacity server začne latence růst nebo procesy skončí nedostatkem paměti.

Má dlouhý import běžet přes PHP-FPM?

Běžně ne. Dlouhá práce blokuje webový worker a zhorší dostupnost běžných requestů. Vhodnější je fronta nebo samostatný CLI worker s vlastním timeoutem, retry a monitoringem.

Je lepší Unix socket, nebo TCP port?

Záleží na topologii. Socket je běžný, když nginx a FPM sdílejí hostitele; TCP je praktické pro oddělené kontejnery. V obou případech je důležité, aby endpoint nebyl veřejně dostupný.

Jak přemýšlím o běhu backendu

Webový request, worker a provozní limit mají mít jasně oddělenou roli.

U PHP aplikací propojuji architekturu, integrační práci a provozní zázemí tak, aby dlouhé úlohy neohrožovaly běžné API a administraci.

Jak přemýšlím o architektuře aplikací Nezávazně probrat projekt