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. Neřeší TLS, veřejné porty, soubory CSS nebo load balancing HTTP klientů. Jeho odpovědností je procesní model PHP, konfigurace poolů, bezpečné oddělení runtime a diagnostika pomalých skriptů. 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.

Vztah k ostatním pojmům

PHP-FPM zpracuje PHP, další vrstvy řeší HTTP, balíčky a provoz.

Oddělení odpovědností brání tomu, aby se problém webového serveru, aplikace a databáze řešil jedním nepřesným nastavením FPM.

nginx: nginx přijímá HTTP, TLS a statické soubory a přes FastCGI předává PHP-FPM dynamické requesty. Délka timeoutu na obou stranách musí být sladěná s typem endpointu.
Docker: FPM může běžet jako samostatná interní služba. Kontejner nemění potřebu spočítat paměť workerů, nastavit health check a chránit socket či port.
Composer: Aplikační worker načítá autoloader a závislosti připravené během buildu. Instalace či update balíčků nemá probíhat v běžícím produkčním requestu.
Symfony a Laravel: Frameworky běží uvnitř requestu obslouženého workerem. Frontové workery, dlouhé importy a plánované úlohy je často lepší oddělit od webového poolu.

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