Ladenie výkonu PHP s PHP-FPM pre systémových administrátorov

Správne vyladenie výkonu PHP-FPM (FastCGI Process Manager) je kľúčové pre rýchlosť a stabilitu webových aplikácií na serveri. PHP-FPM predstavuje preferovaný spôsob prevádzky PHP na moderných serveroch – je flexibilnejší na konfiguráciu a efektívnejší pri obsluhe vysokého počtu požiadaviek než tradičný modul mod_php v Apache. 

Zároveň však predvolené nastavenia konfigurácie PHP-FPM bývajú konzervatívne, aby fungovali „pre každého“; to znamená, že nevyužívajú naplno zdroje výkonnejšieho servera. Bez optimalizácie sa tak môžu objaviť pomalé odozvy pri záťaži, vyčerpanie dostupných PHP procesov a neefektívne využitie CPU, pamäte či diskov. Ladením konfigurácie dokážeme výrazne zrýchliť obsluhu PHP skriptov, zvládnuť viac súbežných používateľov a predísť preťaženiu systému.

Všeobecné odporúčania a zálohovanie

Pred akýmkoľvek zásahom do konfigurácie si vždy zaistite aktuálnu zálohu konfiguračných súborov a overte, že viete vykonať obnovu nastavení. Optimalizačné zásahy môžu viesť k neočakávaným problémom – majte preto pripravený plán návratu k pôvodnému stavu.

Pamätajte, že nižšie uvedené nastavenia a hodnoty sú informatívne odporúčania. Každý server a aplikácia má iné požiadavky, preto ladeniu pristupujte metódou pokus-omyl s priebežným testovaním. Odporúčané hodnoty treba doladiť podľa reálnej záťaže a výsledkov meraní.

Základné pravidlo výkonového ladenia je meniť vždy iba jednu vec naraz a pozorovať vplyv. Ak by ste upravili viac parametrov súčasne a zlepšil by sa (alebo zhoršil) výkon, ťažko zistíte, ktorá zmena mala aký efekt. Preto postupujte iteratívne a trpezlivo.

Prečo PHP-FPM? Rozdiely oproti mod_php

PHP aplikácie môžeme na webovom serveri prevádzkovať rôznymi spôsobmi. Historicky rozšírený bol najmä modul mod_php pre Apache – PHP sa načítalo priamo do procesov webservera. Každá prichádzajúca HTTP požiadavka tak bežala v rámci Apache procesu, ktorý mal do seba vstavaný PHP interpreter. Jednoducho povedané, Apache s mod_php pri spracovaní PHP stránky spustil nový proces (alebo vlákno) a inicializoval v ňom PHP engine. Táto metóda však mala viaceré nevýhody. Musela používať tzv. prefork režim (proces na každé spojenie) kvôli obmedzeniam vlákien v PHP, čo viedlo k vysokej réžii na RAM a CPU pri väčšom počte súbežných požiadaviek. Pre každú požiadavku sa vlastne znovu štartoval PHP interpreter, čo je samozrejme neefektívne.

Naproti tomu PHP-FPM funguje ako samostatný procesový manažér na pozadí. Webový server (či už Apache alebo Nginx) nevybavuje PHP kód priamo, ale odošle ho prostredníctvom protokolu FastCGI do bežiacej služby PHP-FPM. PHP-FPM udržuje pool worker procesov PHP, ktoré sú dopredu spustené a pripravené spracovať prichádzajúce požiadavky bez oneskorenia so štartom procesu. Webserver teda deleguje PHP spracovanie externému procesu – „pošle“ skript do PHP-FPM cez socket alebo TCP port a zoberie si výsledok. Tento prístup prináša viacero výhod:

1. Lepšia efektivita a výkon

Keďže PHP beží ako perzistnentné procesy, nie je potrebné pre každý request štartovať nový proces s interpreterom ako pri mod_php. To šetrí čas aj CPU cykly a umožňuje obslúžiť viac požiadaviek paralelne. Testy ukazujú, že stack s PHP-FPM má vyššiu priepustnosť a stabilitu oproti mod_php. PHP-FPM je dnes považovaný za rýchlejší a flexibilnejší spôsob nasadenia PHP aplikácií.

2. Oddelenie od webservera

PHP-FPM beží nezávisle, vďaka čomu možno webový server (Apache, Nginx) nakonfigurovať úspornejšie. Napríklad Apache môže bežať v režime event/worker MPM, ktorý lepšie škáluje (s mod_php musel používať pomalší prefork). Taktiež je možné PHP-FPM ľahko použiť s Nginxom, ktorý modulárne spúšťanie PHP nepodporuje – Nginx komunikuje s PHP-FPM cez FastCGI socket.

3. Flexibilná konfigurácia a bezpečnosť 

PHP-FPM umožňuje definovať viacero pool-ov procesov s rôznymi nastaveniami (iné počty procesov, iný používateľ/ská skupina, iné php.ini parametre atď.). To je užitočné pri hostingu viacerých aplikácií – každá môže mať vlastný pool (prípadne bežať pod iným systémovým účtom pre zvýšenú izoláciu). V Apache mod_php režime všetko bežalo pod účtom webservera a v rámci jedného procesu, čo zvyšovalo riziko konfliktov a komplikovalo ladenie.

Z historického hľadiska vzniklo PHP-FPM ako patch na PHP cca v roku 2009 s cieľom zlepšiť správu procesov a výkon pre vysoko navštevované weby. Od PHP 5.3 je už súčasťou oficiálneho PHP. V súčasnosti je PHP-FPM predvoleným spôsobom nasadenia PHP na väčšine produkčných serverov, pričom mod_php sa považuje za zastaraný (v novších verziách distribúcií už často ani nie je zahrnutý). 

Architektúra PHP-FPM a správa procesov

Aby sme pochopili ladenie PHP-FPM, pozrime sa stručne na to, ako PHP-FPM manažuje procesy. PHP-FPM beží ako master daemon (proces) php-fpm, ktorý spúšťa a riadi viacero worker procesov (tie vykonávajú samotný PHP kód). Po štarte načíta nastavenia z konfiguračného súboru (typicky /etc/php/8.X/fpm/php-fpm.conf a pool definície v priečinku pool.d/). Každý pool predstavuje skupinu procesov obsluhujúcich jednu alebo viac webových lokalít. Najčastejšie existuje aspoň pool [www], ktorý obsluhuje webové požiadavky z default webu. Môžeme však definovať vlastné pooly pre rôzne stránky alebo časti aplikácie (napr. frontend vs. backend e-shopu) a odlišne ich nakonfigurovať.

Komunikácia: Webserver (napr. Nginx) posiela požiadavky na PHP skripty PHP-FPM procesu cez tzv. FastCGI socket (môže to byť Unix socket súbor, napr. /var/run/php/php-fpm.sock, alebo sieťový port, napr. 127.0.0.1:9000). PHP-FPM neustále počúva na tomto sockete. Keď príde požiadavka, PHP-FPM ju odovzdá jednému zo svojich voľných worker procesov, ktorý vykoná PHP kód a vráti výsledok (HTML/JSON atď.) webserveru. Ak v danom momente nie je žiadny voľný worker (všetky sú zaneprázdnené spracovaním iných požiadaviek), PHP-FPM sa môže pokúsiť vytvoriť nový proces (ak to povoľuje nastavenie) alebo – ak už dosiahol strop povolených procesov – musí ďalšie požiadavky zaradiť do fronty (alebo odmietnuť). Práve parametre určujúce koľko procesov môže bežať a ako sa správa fronta patria k najdôležitejším pre ladenie výkonu.

Na strane webservera je dôležité spomenúť parameter listen.backlog v konfigurácii PHP-FPM. Určuje veľkosť fronty nevybavených požiadaviek na sockete – napríklad nastavenie listen.backlog = 65535 zvýši kapacitu fronty pre extrémne zaťaženie (predvolená hodnota býva nižšia). Pri vysokom počte súbežných spojení by príliš malý backlog mohol spôsobiť odmietanie nových spojení ešte skôr, než ich PHP-FPM stihne prijať. Webserver (Nginx) by v takom prípade logoval chyby typu “connect() to unix:/var/run/php-fpm.sock failed (11: Resource temporarily unavailable)”, čo indikuje plný backlog. Preto na vysoko záťažových serveroch zvýšte listen.backlog (alebo nastavte na -1, čo znamená “bez limitu”, resp. použitie maxima povoleného systémom).

Režimy správy procesov: static, dynamic, ondemand

PHP-FPM ponúka tri spôsoby (“process manager” režimy), akými riadi počet worker procesov. Tento parameter pm môže nadobudnúť hodnoty static, dynamic alebo ondemand. Voľba správneho režimu výrazne ovplyvní výkon a spotrebu zdrojov:

Static

FPM spustí pevne daný počet PHP procesov a udržuje ich stále aktívne. Počet sa nastavuje direktívou pm.max_children. V režime static je vždy spustený maximálny počet procesov, bez ohľadu na aktuálnu záťaž . Výhodou je, že požiadavky nikdy nemusia čakať na štart nového procesu – latencia je minimálna. Ide teda o najrýchlejší prístup, vhodný pre vysoko návštevné weby, kde je potrebné okamžite obslúžiť veľké množstvo dopytov. Nevýhodou je vyššia spotreba pamäte aj pri nízkej záťaži (veľa nečinných procesov zaberá RAM) a potenciálne plytvanie prostriedkami, ak traffic kolíše. Static využíva naplno zdroje servera, preto sa oplatí len ak ich máte dostatok. Na serveroch s dostatočnou RAM a stabilne vysokou návštevnosťou prináša režim static najvyššiu priepustnosť.

Dynamic

Ide o predvolený režim vo väčšine distribúcií. Počet procesov sa dynamicky prispôsobuje záťaži v rámci definovaných medzí. Konfigurácia obsahuje päť kľúčových parametrov: pm.max_children (maximálny počet procesov), pm.start_servers (koľko procesov spustiť pri štarte), pm.min_spare_servers (minimálny počet voľných – nečinných – procesov, ktoré má PHP-FPM vždy udržiavať), pm.max_spare_servers (maximálny počet voľných procesov) a pm.process_idle_timeout (doba nečinnosti, po ktorej sa nadbytočný proces ukončí). V dynamickom režime PHP-FPM vždy udržuje aspoň pm.min_spare_servers voľných procesov pripravených. Ak príde viac požiadaviek, než je momentálne procesov, PHP-FPM môže spúšťať nové procesy (až kým ich celkový počet nedosiahne pm.max_children). Naopak, keď opadne záťaž a voľných procesov je viac než pm.max_spare_servers, nadbytočné sa ukončia.

Tento režim je flexibilný – snaží sa mať dostatok procesov, ale zároveň neudržuje zbytočne veľa nečinných workers. Je vhodný pre väčšinu bežných aplikácií s premenlivým trafficom. Treba ho však správne naladiť, aby pri špičke stíhal (dostatok max_children) a pri nízkej záťaži zbytočne „nežral” pamäť (primerané spare parametre). Nesprávne nastavenie môže viesť k správam v logu typu “[pool…] seems busy, spawning children…” , čo naznačuje, že PHP-FPM musel často dynamicky štartovať procesy – vtedy treba zvýšiť start_servers či min_spare_servers.

Ondemand

V tomto režime PHP-FPM procesy nespúšťa dopredu vôbec žiadne (alebo len minimum) a vytvára ich až keď prídu požiadavky. Po určitom čase nečinnosti procesy opäť ukončí. Konfigurácia tu používa parametre pm.max_children (maximálny povolený počet procesov) a pm.process_idle_timeout (koľko sekúnd po obsluhe požiadavky proces čaká nečinný, kým ho PHP-FPM ukončí). Parametre ako start_servers či spare_servers sa pri ondemand režime ignorujú (nemajú zmysel). Výhodou ondemand je minimálna spotreba pamäte v období nízkej alebo nulovej záťaže, pretože nebežia žiadne zbytočné procesy. Hodí sa to napríklad pre menej využívané administrátorské rozhrania, alebo pri multihostingu so stovkami webov, z ktorých väčšina je väčšinu času bez návštevníkov.

Nevýhodou môže byť latencia pri náhlom príchode novej záťaže. Oneskorenie býva pri prvom hite zvyčajne v desiatkach milisekúnd (často pod ~100 ms) z nášho testovania na modernom hardvéri. Tiež časté vytváranie a ničenie procesov mierne zvyšuje režijnú záťaž a fragmentáciu pamäte. Ondemand teda nie je ideálny pre vysokú premávku, kde neustále prichádzajú požiadavky – tam by procesy aj tak nikdy nestihli „odumrieť” a overhead by bol zbytočný.

Voľba režimu závisí od charakteru vášho webu: Pre malé alebo zriedka navštevované stránky (napr. interné administrácie) je vhodný ondemand – ušetrí RAM tým, že procesy bežia iba keď treba. Používateľ občas toleruje mierne zdržanie pri prebúdzaní procesu. Naopak pre vysoko zaťažené weby s množstvom requestov za sekundu (napr. e-shopy, spravodajské weby) sa odporúča static s dostatočne vysokým pm.max_children, aby boli všetky požiadavky okamžite obslúžené. Aj keď to znamená veľa nečinných procesov, dôležité je, že pri špičkovom návale nebudú vzniknúť oneskorenia kvôli spúšťaniu procesov a server využije naplno svoju kapacitu. Režim dynamic predstavuje kompromis a najčastejšie sa využíva pri stredne variabilnej záťaži, kde nechceme úplne plytvať prostriedkami ako static, ale ani riskovať latencie ako pri ondemand. Pravdupovediac, správna odpoveď na otázku „ktorý režim je najlepší“ je závisí od situácie – treba zvážiť profil vášho trafficu a možnosti servera.

Režim (a sprievodné parametre) možno nastaviť pre každý pool samostatne. Pokojne môžete na jednom serveri prevádzkovať viac pool-ov, z ktorých jeden (napr. pre frontend) pôjde v režime static a iný (napr. pre málo používaný backend/admin) v režime ondemand. Tým dosiahnete, že kritická časť aplikácie má garantovaný výkon a menej dôležitá časť šetrí zdroje, keď ju nik nevyužíva.

Dôležité parametre konfigurácie PHP-FPM

Pri ladení výkonu PHP-FPM sa zamerajte najmä na nasledujúce kľúčové nastavenia v konfiguračnom súbore poolu (štandardne /etc/php/8.x/fpm/pool.d/www.conf pre pool menom „www“):

• pm.max_children: Maximálny počet PHP procesov (workerov), ktoré smie PHP-FPM spustiť. Toto je kritický parameter ovplyvňujúci, koľko súbežných PHP požiadaviek server obslúži. Pri static režime určuje fixný počet procesov. Pri dynamic/ondemand režime predstavuje hornú hranicu, ktorú PHP-FPM neprekročí – ak príde viac požiadaviek než je max_children, zvyšné musia počkať vo fronte (alebo dostanú chybu 503, ak je fronta plná). Nastavenie pm.max_children preto musí zohľadniť hardvérové zdroje (najmä RAM) a očakávanú špičkovú záťaž. Ako ho vypočítať si ukážeme v ďalšej časti.
• pm.start_servers: (Len pre dynamic) Počet PHP procesov, ktoré sa spustia pri štarte PHP-FPM. Nastavte ho podľa očakávanej bežnej záťaže tak, aby krátko po štarte nevznikal nedostatok procesov. Bežné odporúčanie je 4 × počet CPU jadier, no môže to závisieť aj od pamäte. Pri našom ukážkovom VPS (4 vCPU, 16 GB RAM) by mohlo dávať zmysel napríklad ~16-32 procesov pri štarte (ak očakávame, že hneď od spustenia pôjde viac requestov). Príliš vysoké číslo však môže zbytočne alokovať pamäť pre nečinné procesy.
• pm.min_spare_servers, pm.max_spare_servers: (Len pre dynamic) Minimálny a maximálny počet voľných (idle) procesov, ktoré PHP-FPM udržuje . Ak počet nečinných procesov klesne pod min_spare, PHP-FPM vytvorí nové procesy (pokiaľ nie je dosiahnutý max_children). Naopak, ak voľných procesov je viac než max_spare, PHP-FPM niektoré ukončí. Tieto parametre pomáhajú vyhladzovať výkyvy záťaže. Odporúčania bývajú min_spare ~ 2 × CPU jadrá a max_spare ~ 4 × CPU jadrá (resp. rovnaké ako start_servers) . V praxi: ak máte 4-jadrový server, skúste napr. min_spare = 8, max_spare = 16 (samozrejme v medziach max_children). Pri vyššej návštevnosti tieto hodnoty zvyšujte. Ak v logoch vidíte časté správy o spúšťaní procesov (“seems busy… spawning … children”), znamená to, že min_spare je príliš nízke a PHP-FPM nestíha predvídať špičku – zvyšujte ho. No a naopak, ak máte trvalo veľa nečinných procesov aj mimo špičky, môžete max_spare znížiť, aby zbytočné procesy uvoľnili pamäť.
• pm.process_idle_timeout: (Pre dynamic aj ondemand) Čas v sekundách, ako dlho nechá PHP-FPM nečinný proces bežať predtým, než ho ukončí. V dynamickom režime sa takto odstraňujú nadbytočné procesy (keď ich je viac než min_spare). V ondemand režime je to kľúčový parameter – určuje, ako rýchlo sa pool “uspí” pri nečinnosti. Predvolená hodnota býva 10s. Môžete ju zvýšiť, ak nechcete príliš agresívne vypínať procesy (aby sa nereštartovali priskoro medzi krátkymi burstami trafficu). Naopak, na systémoch s obmedzenou RAM môžete timeout znížiť, nech sa pamäť skôr uvoľní. Napríklad v cPanel prostredí s mnohými webmi defaultne nastavujú vyšší idle timeout alebo priamo ondemand režim, aby nezahltili RAM veľkým počtom nečinných procesov.
• pm.max_requests: Maximálny počet požiadaviek, ktoré jeden PHP proces obslúži, kým ho PHP-FPM ukončí a nahradí novým. Predvolená hodnota je 0 (neobmedzene), čo znamená, že procesy bežia neustále. Nastavenie nenulovej hodnoty (napr. pár stoviek) sa odporúča, ak vaša aplikácia alebo rozšírenia PHP môžu mať memory leaky. Postupné zvyšovanie spotreby pamäte procesov sa takto „vynuluje“ ich periodickou recykláciou. V opačnom prípade by dlhodobo bežiaci worker mohol narásť a ohroziť stabilitu. Hodnota 0 (neobmedzene) maximalizuje výkon tým, že eliminuje overhead neustáleho re-spawnovania procesov. Ako vždy, kompromis závisí od aplikácie: ak ste si istí, že žiadne memory leaky nemáte, môžete nechať pm.max_requests vysoké (alebo 0). Napríklad pri použití režimu static na výkonnom serveri bez memory leakov niektorí odporúčajú pm.max_requests = 0 pre maximálny výkon. V opačnom prípade je rozumné nastaviť napr. 200-500, aby sa procesy raz za čas obnovili. Pri veľmi vysokej záťaži a stabilnej aplikácii sa osvedčilo aj nastavenie vyšších hodnôt (1000+ alebo neobmedzene) na minimalizáciu resetov. Sledujte však správanie – ak vidíte rastúcu pamäť procesu v čase, radšej limitujte max_requests.
• memory_limit (php.ini): Hoci nejde o parameter PHP-FPM ako taký, priamo ovplyvňuje koľko pamäte môže jeden PHP proces spotrebovať (limit pre PHP skript). Štandardne býva 128M alebo 256M na proces. Je dôležité uvedomiť si, že ak nastavíte memory_limit veľmi vysoko (napr. 512M či 1G), teoreticky jeden PHP proces môže toľko RAM aj zabrať. To potom drasticky znižuje počet procesov, ktoré sa zmestia do pamäte servera. Pri výpočte pm.max_children sa často ako hrubý odhad používa práve memory_limit (alebo ešte lepšie reálna priemerná spotreba procesu) . Odporúčanie je nemať zbytočne vysoký memory_limit, iba ak aplikácia naozaj spracúva objemné dáta. Pre väčšinu webov 128-256 MB postačuje. Tiež započítate pamäť pre OPCache (viď nižšie) – tá sa síce zdieľa medzi procesmi, ale ukrojí pár stoviek MB z RAM.
• max_execution_time, request_terminate_timeout: Tieto nastavenia (prvé v php.ini, druhé v PHP-FPM conf) určujú, ako dlho smie PHP skript bežať, kým ho ukončíme. max_execution_time je limit na úrovni PHP (pre každý request), request_terminate_timeout je tvrdý limit na úrovni PHP-FPM worker procesu. Pri ladení výkonu ich môžete nastaviť vyššie, ak viete, že niektoré skripty legitímne trvajú dlhšie (napr. generovanie reportov), aby neboli predčasne zabité. Na druhej strane, extrémne dlhé behy skriptov blokujú worker proces a zvyšujú frontu – treba zvážiť optimalizáciu takých skriptov alebo ich spúšťanie mimo web požiadavky (cron joby). Typicky sa ponechávajú defaulty (30s alebo 60s). Pre vysoko konkurenčné prostredie s riskom zaseknutia procesov je vhodné mať nastavený nejaký timeout (napr. 300s), aby uviaznutý proces nezostal visieť navždy a nebral zdroje.
• OPcache: Jedna z najväčších “ladiacich” výhier mimo samotného PHP-FPM je zapnutie a správna konfigurácia PHP OPcache. Ide o caching mechanizmus, ktorý uchováva skompilovaný bytecode PHP skriptov v zdieľanej pamäti. Výsledkom je, že pri opakovanom volaní toho istého PHP súboru sa už nemusí znovu parsovať a kompilovať do opkódov – skracuje sa vykonávanie o tieto kroky. Bez OPcache každý request „znova” interpretuje PHP kód, čo plytvá CPU aj časom. Zapnutý OPcache dramaticky znižuje zaťaženie CPU (v testoch klesol priemer čas spracovania PHP aj o 80% ) a zároveň mierne znižuje pamäťovú stopu procesov (keďže zdieľajú skompilovaný kód). Od PHP 8.0 je OPcache bežne súčasťou inštalácie, len ho treba povoliť v php.ini (nastavením opcache.enable=1 a opcache.memory_consumption=…). Pre produkčný server odporúčame OPcache vždy zapnúť a nastaviť mu dostatočne veľkú pamäť (podľa veľkosti vášho kódu – napr. 128 MB, 256 MB alebo aj viac pre veľké aplikácie). Sledujte metriky OPcache (využitie vyrovnávacej pamäte) – ak dosahuje 100% a cache sa preplňuje, zvyšujte pamäť, inak dochádza k tzv. cache misses a výkon klesá. Opäť však s mierou – zbytočne veľká cache je nevyužitá RAM.
• slowlog: PHP-FPM umožňuje zaznamenať pomalené skripty – tie, ktoré bežia dlhšie než definovaný časový limit. Parametre request_slowlog_timeout nastavte na prah (v sekundách), po ktorom sa považuje request za „pomalý“ a slowlog určite cestu k log súboru . Napr. môžete pridať do konfigurácie pool-u:

request_slowlog_timeout = 5s

slowlog = /var/log/php-fpm/slow.log

To spôsobí, že ak nejaký PHP request beží dlhšie než 5 sekúnd, PHP-FPM do uvedeného súboru vypíše diagnostiku (vrátane backtrace, ak povolíte request_slowlog_trace_depth, napr. 20 ). Slowlog je nesmierne užitočný pri ladení – pomôže vám identifikovať, ktoré PHP skripty alebo funkcie zdržujú spracovanie. Môžete tak zistiť, že vás brzdí napríklad pomalé volanie databázy, externá API alebo neefektívny algoritmus. Optimalizácia kódu je často najlepším liekom na výkonové problémy, ktoré žiadne ldenie PHP-FPM neodstráni. Nezabudnite však riešiť rotovanie tohto logu (napr. cez logrotate), aby sa časom nezaplnil disk .

• listen.mode, owner, group: Tieto parametre určujú práva socketu, ak používate Linux socket na prepojenie s webserverom. Z výkonového hľadiska sú irelevantné, ale spomenieme ich – ak meníte užívateľa, pod ktorým PHP-FPM procesy bežia (user/group direktívy poolu), upravte aj listen.owner a listen.group, aby socket mal správne oprávnenia. listen.backlog sme už spomínali vyššie (viď architektúra).
• rlimit_files, rlimit_core: Týkajú sa limitov OS – max. počet súborových descriptorov a generovanie core dump súborov. Pre vysokú záťaž môže byť potrebné zvýšiť rlimit_files, ak vidíte chyby typu “too many open files”. Nastavenie napr. rlimit_files = 65535 zdvihne limit na počet otvorených súborov/súborových descriptorov pre PHP-FPM proces . To môže zahŕňať sieťové sockety, otvorené logy, atď. rlimit_core = unlimited povoľuje vytvorenie core dumpu pri páde procesu (užitočné pre debug, inak nepotrebné). Tieto nastavenia sú voliteľné a väčšinou netreba meniť, pokiaľ explicitne nenarazíte na príslušné limity.

Výpočet optimálneho počtu procesov a pamäťové nároky

Hodnota pm.max_children zásadne ovplyvňuje pamäťové nároky PHP-FPM. Každý PHP proces zaberá určitú pamäť (vyhradenú aj zdieľanú). Cieľom je využiť dostupnú RAM efektívne, no nepresiahnuť ju. Ak nastavíte priveľa procesov, môžu zaplniť RAM a systém začne swapovať (čo drasticky spomalí server), alebo v horšom prípade OOM killer začne zabíjať procesy. Naopak príliš nízka hodnota nechá nevyužitú pamäť a obmedzí počet súbežných requestov, ktoré zvládnete.

Základný postup výpočtu: Zistite, koľko pamäte priemerne zaberá jeden PHP-FPM proces vo vašej záťaži a vydeľte dostupnú pamäť touto veľkosťou. Tým dostanete hrubý odhad maximálneho možného počtu procesov. Napríklad, ak jeden proces potrebuje ~60 MB a máte pre PHP k dispozícii ~600 MB RAM, teoreticky by ste mohli mať až 10 procesov (600/60). Samozrejme, nechceme ísť na doraz – vždy nechajte rezervu pre OS a iné služby (webserver, databáza atď.) a tiež pre výkyvy. Často sa odporúča ponechať 20-30 % RAM voľnej ako buffer. Rovnako rátajte s tým, že nie každý proces vždy vyťaží maximum memory_limit – priemer môže byť výrazne nižší než limit, pokiaľ veľa requestov robí len malé úlohy.

Ako zistiť veľkosť procesu? Môžete využiť napríklad skript ps_mem.py alebo príkaz ps/top. Príklad:

# Vypočíta priemernú RSS pamäť PHP-FPM procesov

ps --no-headers -o "rss,cmd" -C php-fpm8.1 | awk '{ sum+=$1 } END { printf ("%dM\n", sum/NR/1024) }'

Tento príkaz spočíta Resident Set Size (RSS) – reálne obsadenú fyzickú pamäť – PHP procesov a dá priemer. Povedzme, že výsledok je ~50 MB na proces. Ak náš server má 16 GB RAM a okrem PHP na ňom beží už len OS a webserver, môžeme napr. rezervovať 2-4 GB pre systém a zvyšných ~12-14 GB pre PHP-FPM. Pri 50 MB/proces by teoretické maximum bolo 240-280 procesov. Z toho vezmeme napríklad 80 % (necháme 20 % rezervu) – čiže okolo 190-220 procesov by mohol systém utiahnuť

V praxi by sme zvolili konzervatívnejšie, povedzme pm.max_children = 150 (čo je asi 7.5 GB pri 50 MB/proces). Postupne môžeme ladiť: sledovať vyťaženosť a prípadne zvyšovať, ak je pamäť stále voľná a súčasne vidíme, že by sa zišlo viac paralelných procesov (napr. fronta požiadaviek v stave Waiting). Nikdy nezačínajte extrémne vysoko – radšej postupne pridávajte, inak riskujete pád servera pri špičke.

Pre náš konkrétny príklad VPS s 4 vCPU a 16 GB RAM si ukážeme orientačný výpočet. Predpokladajme, že beží len webový server a PHP (databáza je na inom stroji, takže väčšinu pamäte môžeme dať PHP). OS a demonov (SSH, syslog atď.) necháme ~2 GB, čiže zostáva ~14 GB pre PHP-FPM. Koľko zaberá proces? Záleží od aplikácie – jednoduchý WordPress môže brať 30-50 MB na request, robustný e-shop aj 100+ MB. Ak nastavíme memory_limit = 256M, neznamená to, že každý proces toľko aj zoberie, ale mal by mať tú možnosť. Pre hrubý odhad zoberme napr. 128 MB na proces (to už pokryje aj náročnejšie skripty). (14 GB dostupných) / (128 MB) = 112 procesov. Odporúčanie je nevyužiť všetko, ale tak ~75-80 %. 80 % zo 112 je ~90 procesov.

Môžeme teda nastaviť pm.max_children = 90 ako štartovací bod. Naše CPU (4 jadrá) zvládnu 90 paralelných vlákien len v prípade, že väčšina z nich nečaká na CPU (napr. čakajú na I/O). To je reálny scenár – pri webových aplikáciách mnohé procesy čakajú na odpoveď DB, diskové operácie, sieť atď., takže viac procesov než jadier dáva zmysel. Ak by však vaša aplikácia bola extrémne CPU náročná (vedecké výpočty v PHP a pod.), tak by 90 simultánnych behov preťažilo CPU – v takom prípade by ste volili číslo bližšie počtu jadier (napr. 8 procesov na 4 jadra, čo umožní hyperthreading). Pre drvivú väčšinu webov je však bottleneck inde než čistý CPU, preto nastavenie vyššieho počtu procesov umožní lepšie využiť čas, keď procesy čakajú.

Naše zvolené pm.max_children = 90 ďalej doladíme parametrami pre dynamic režim. Povedzme, že zvolíme pm = dynamic (rozumné pre začiatok). Podľa odporúčaní nastavíme: pm.start_servers = 8 (2 × vCPU alebo ~10 % z max_children), pm.min_spare_servers = 8, pm.max_spare_servers = 20. Čiže pri štarte pobeží 8 procesov a v rezerve budeme držať 8-20 voľných podľa potreby. Konfigurácia by mohla vyzerať napríklad takto:

pm = dynamic

pm.max_children = 90

pm.start_servers = 8

pm.min_spare_servers = 8

pm.max_spare_servers = 20

pm.max_requests = 500

(Uvádzame pm.max_requests = 500 ako určitú poistku pred leakmi – konkrétna hodnota závisí od aplikácie.) Takáto konfigurácia by mala zabezpečiť stabilitu pri vysokom počte súbežných užívateľov, pričom nevyčerpá úplne 16 GB RAM. Samozrejme, skutočný ideál môže byť iný – musíme to otestovať.

Automatizované nástroje: Existujú kalkulačky a skripty, ktoré vám vygenerujú odporúčané nastavenia na základe parametrov servera. Napríklad online nástroj Spot13 PM Calculator umožňuje zadať celkovú RAM, rezervovanú RAM, percento bufferu a veľkosť procesu – a vypočíta hodnoty max_children, start/min/max_spare. Ďalej je tu skript php-fpm_tuner. Keď ho spustíte na bežiacom serveri, prepočíta odporúčania podľa aktuálne voľnej pamäte a reálnej veľkosti PHP procesov. Výstup napríklad:

pm.max_children = 11
  
pm.start_servers = 3
  
pm.min_spare_servers = 3
  
pm.max_spare_servers = 8

Takýto nástroj je užitočný na prvé nastrelenie hodnôt, ale berte ho s rezervou. Nevidí špecifiká vašej aplikácie ani špičky trafficu. Preto výsledky zo skriptu vždy overujte v praxi a kombinujte s vlastným monitoringom.

Napokon, pri nastavovaní počtu procesov nezabúdajte na iné služby. Ak na tom istom serveri beží napr. databáza MySQL, treba jej nechať dostatok RAM (MySQL si vie z RAM vziať aj niekoľko GB). V takom prípade nemôžete všetku voľnú pamäť nasadiť na PHP. Pri našom príklade 16 GB VPS by bežiaca MySQL s cache zaberala povedzme 4-6 GB, systém 2 GB, zostane 8-10 GB pre PHP – čiže max_children by sme úmerne znížili (napr. na ~50-60). Vždy myslite na celý stack, nielen PHP samotné.

Monitorovanie výkonu a ladenie konfigurácie

Po aplikovaní zmien v konfigurácii (a reštarte služby PHP-FPM) je nevyhnutné sledovať správanie servera. Performance tuning nekončí úpravou súborov – musíme overiť, či zmeny priniesli zlepšenie a či nevznikli nové problémy.

1. Kontrola logov 

Sledujte PHP-FPM error log (typicky /var/log/php8.x-fpm.log). Hľadajte varovania ako “server reached pm.max_children setting, consider raising it” – to značí, že ste narazili na limit a požiadavky museli čakať alebo boli odmietnuté. Ak také hlásenia vidíte často a zároveň máte ešte voľnú RAM, je na mieste zvýšiť pm.max_children. Ďalej správy o spúšťaní/kille procesov v dynamickom režime: “… seems busy, spawning …”, “… killing spare child …” prezradia, či nastavenia min/max_spare sú primerané. Tie občasné záznamy sú normálne, ale ak vidíte neustále spawnovanie procesov, možno máte start_servers alebo spare prahy primalé. Naopak, ak často killuje spares, možno ich máte priveľa – ale to nie je kritický problém, skôr znak, že by sa dalo trochu pamäť ubrať.

Ak používate slowlog, analyzujte ho. Každý záznam slowlogu znamená request, ktorý bežal nad stanovený limit (napr. 5s). Skúste zistiť, prečo – ak je to neopodstatnené (napr. zle napísaná SQL query), riešením je optimalizácia kódu či databázy, nie úprava PHP-FPM. Cieľom ladenia je aj identifikovať užšie miesta aplikácie (bottlenecks). PHP-FPM parametre pomôžu zvýšiť priepustnosť, ale ak máte jeden skript, ktorý vždy beží 30 sekúnd, tak 100 paralelných procesov vám akurát vyťaží CPU a databázu, ale odpoveď aj tak potrvá 30 sekúnd – to musíte riešiť inak (napr. optimalizovať algoritmus, rozdeliť úlohu, cachovať výsledky atď.).

2. Sledovanie systémových zdrojov 

Pomocou nástrojov ako htop či top sledujte využitie CPU, pamäte a swapu. V ideálnom prípade po vyladení uvidíte, že CPU je využité povedzme na 70 % pri špičke (predtým možno nestíhalo alebo naopak bolo nevyužité) a pamäť je využitá napr. na 80 % bez swapovania. Ak začnete swapovať (výrazný nárast IO, systémová RAM 100% plná a obsadený swap), to je červená kontrolka – príliš veľa procesov alebo príliš veľký memory_limit. Okamžite zasiahnuť (znížiť pm.max_children alebo pridať pamäť). Tiež sledujte počet bežiacich procesov PHP-FPM v reálnom čase – buď cez ps/pgrep, alebo si môžete povoliť status stránku PHP-FPM.

3. PHP-FPM status page 

V konfigurácii pool-u viete aktivovať pm.status_path, napríklad pm.status_path = /fpm_status. Keď potom požiadate webserver (napr. curl http://localhost/fpm_status v Nginx, podľa nastaveného location), PHP-FPM vráti textový prehľad: aktuálny počet procesov (idle/busy), nastavene limity a prípadne dĺžku fronty. Je to veľmi užitočné na zistenie, či máte veľa voľných procesov alebo naopak často všetky busy a requesty vo fronte. Metriku max children reached (koľkokrát bol dosiahnutý limit) tam tiež nájdete. Pri ladení odporúčame dočasne povoliť status (môžete ho zabezpečiť napr. IP adresou alebo heslom, aby nebol verejný) a pozerať, čo ukazuje počas záťažových testov či reálnej premávky.

4. Záťažové testovanie (stress test) 

Ak je to možné, vykonajte testy výkonnosti mimo produkčnej špičky alebo na testing prostredí. Môžete použiť nástroje ako Apache Bench (ab), wrk, JMeter, či dokonca jednoduchý skript vo curl slučke, ktorý pošle X paralelných požiadaviek na váš server. Simulujte reálny scenár – pozor na cache! Ak máte HTTP cache (napr. stránka generuje statický obsah do cache) alebo CDN, otestujte aj cache MISS scenáre. Bežná chyba je vyladiť PHP-FPM na kešované stránky (ktoré PHP takmer nezaťažia) a potom pri reálnej prevádzke na nekešované requesty server padne.

Počas testu sledujte metriky: latencie odpovedí (či nestúpajú pri záťaži), využitie CPU/RAM, logy. Skúste záťaž postupne zvyšovať. Ak napr. pri 50 paralelných užívateľoch je všetko OK, ale pri 200 už začne stúpať response time alebo objavia sa chyby 502/503, viete, kde asi máte strop. Vtedy možno treba pridať procesy (ak je ešte pamäť) alebo ide o limit CPU a pomohlo by škálovanie na viac jadier. Záťažové testy pomôžu overiť stabilitu – ak PHP-FPM padá alebo sa zadrháva pri vysokom počte requestov, radšej to odhaľte testom, než aby vás to zaskočilo v ostrej prevádzke.

5. Jemné dolaďovanie 

Na základe pozorovaní môžete konfiguráciu ďalej dolaďovať. Napríklad: ak vidíte, že máte stále >30 % voľnej RAM aj pri špičke a fronta requestov sa občas tvorí, skúste zvýšiť pm.max_children o 10-20 % a znova testovať. Alebo ak vidíte, že nikdy nemáte viac než 50 aktívnych procesov, pokojne môžete znížiť max_children a ušetriť pamäť pre iné účely. Tiež sledujte CPU load pri statickom vs. dynamickom režime: Niektorí správcovia zaznamenali, že pri static režime je CPU záťaž plynulejšia a pri dynamickom kolíše viac (kvôli spawn/kill procesov). Ak load average veľmi skáče a CPU občas ide do 100 %, static by mohol pomôcť – samozrejme ak máte pamäť. Naopak, ak CPU je väčšinu času nízko a pamäť je kritická, dynamic/ondemand ušetrí pár percent výkonu výmenou za výraznú úsporu RAM.

Pri ladení výkonu sa občas používa technika „vybudenia” systému – záťažový test s postupným zvyšovaním intenzity až kým sa neobjavia prvé problémy. Zistíte tak bod zlomu (break point). Napr. testujte so 100, 200, 300 paralelnými požiadavkami… až pri 300 začnú time-outy. To ukazuje, že konfigurácia zvláda ~250 concurrency, ale 300 už nie. Potom buď zlepšíte konfiguráciu (ak sú rezervy), alebo viete, že fyzicky ten stroj viac nezvládne a museli by ste škálovať horizontálne (viac serverov za loadbalancer) či vertikálne (výkonnejší server). Ladenie PHP-FPM má svoje limity – ak narazíte na strop daný HW, ďalšie zvyšovanie parametrov nepomôže a môže uškodiť.

Viacero pool-ov a oddelenie služieb

Ako už bolo spomenuté, PHP-FPM umožňuje definovať viac pool-ov procesov. Každý pool funguje ako samostatná skupina PHP procesov s vlastným nastavením. V praxi toho využijete v týchto scenároch:

1. Oddelenie rôznych webových aplikácií na jednom serveri 

Ak hostujete viac webov, odporúča sa každému vyhradiť vlastný PHP-FPM pool (často aj bežiaci pod iným systémovým užívateľom kvôli bezpečnosti). Výhody sú: lepšia izolácia (pád alebo zahltenie jedného poolu nezhodí ostatné), možnosť ladiť nastavenia na mieru každej aplikácii (napr. e-shop potrebuje viac procesov, malý firemný web menej), a prehľadnosť – v logoch vidíte ktorý pool hlási chyby. V konfiguračných súboroch potom budete mať bloky označené [nazov_poolu] a pre každý vlastné pm, pm.max_children, atď. Nginx/Apache vhost konfigurácia musí byť upravená, aby príslušné URL smerovali na správny socket/port poolu. Toto je štandard pri webhostingu a určite odporúčané, ak spravujete heterogénne aplikácie (napr. WordPress + Laravel + Joomla na jednom stroji – každé má iný profil záťaže, iné memory_limit požiadavky, takže dajte im oddelené pool-y).

2. Rozdelenie frontendu a backendu jednej aplikácie 

Aj v rámci jednej aplikácie (ak je robustná) môžete výkonnostne oddeliť časti. Typický príklad je CMS alebo e-shop s frontendom (verejná stránka pre zákazníkov) a backendom (administrácia pre redakciu). Frontend má veľa požiadaviek od návštevníkov, musí byť rýchly a škálovať – tam nasadíte pool s viacerými procesmi, možno static alebo dynamic s vysokými limity. Backend používajú len redaktori občas – tam stačí pár procesov a pokojne ondemand (nech nám napríklad zbytočne nežerú RAM, keď v noci nikto v redakcii nepracuje). Nastavenie je jednoduché: vytvoríte dva pooly (napr. [frontend] a [backend]) v konfigurácii a v Nginx konfigurácii podľa URL alebo domény nasmerujete požiadavky buď na frontend alebo backend socket. Takto viete zabezpečiť, že ak náhodou admin časť spustí náročnú operáciu (napr. import produktov), nevyčerpá všetky PHP procesy a frontend pre zákazníkov bude stále reagovať (pretože má vlastný pool).

3. Multi-tenancy (veľa poolov) 

Ak hostujete stovky webov (napr. v rámci jedného VPS alebo kontajneru), počet pool-ov sa rovná počtu webov. Tam nastupuje to, že static či dynamic režim by pri 100 pooloch bol neúnosný (100×20 procesov = 2000 procesov v pamäti stále). Preto napr. cPanel v takých scenároch používa ondemand pre každý pool, aby pooly, ktoré nemajú traffic, nemali žiadny proces a nebrali pamäť. Administrátor potom musí voliť parametre tak, aby sumárne všetky pooly neprekročili kapacity. Často ide o kompromis – napr. nastaviť max_children nižšie, než by si mohol dovoliť každý web samostatne, lebo pri 100 weboch by to už prekročilo RAM. Toto je komplexná problematika (ladenie multi-tenant servera) – odporúčame vtedy robustnejší monitoring, kontajnerizáciu alebo rozdelenie záťaže na viac serverov, ak je možnosť.

Nástroje na testovanie a ladenie

Spomeňme niekoľko užitočných nástrojov a postupov, ktoré administrátorovi pomôžu pri ladení PHP-FPM:

• Online kalkulačky: Už sme zmienili Spot13 PHP-FPM Calculator. Podobný jednoduchý kalkulátor ponúka aj Tideways vo forme webovej aplikácie. Zadať musíte parametre RAM, CPU, odhad veľkosti procesu a zvolíte typ pm (static/dynamic) – nástroj vypľuje odporúčané nastavenia. Berte to ako východiskový bod, nie dogmu. Skutočné hodnoty si overte v prevádzke.
• Skripty tretích strán: php-fpm_tuner sme už popísali – stačí stiahnuť php-fpm-tuner.php a spustiť v príkazovom riadku na serveri . Skript zistí voľnú RAM, spočíta priemernú veľkosť procesu (buď z bežiacich, alebo použije memory_limit) a navrhne pm.max_children, start_servers, atď. Výhodou je, že zohľadní aj počet CPU jadier (aby nenavrhol nezmyselne veľa procesov). Nevýhodou môže byť, že ak skript spustíte v neaktívnom čase, nameria menšie procesy než v špičke – čiže odhadne viac children, než reálne treba (čo by v špičke mohlo byť veľa). Preto ideálne pustite tuner počas typickej záťaže. 
• Monitoringové nástroje: Na kontinuálne sledovanie výkonu odporúčame nasadiť nejaký monitorovací systém. Môže to byť komplexné APM (Application Performance Monitoring) riešenie ako New Relic, Datadog atď., ktoré okrem metriky servera sleduje aj profil aplikácie. Ak taký nástroj nemáte, aspoň si nastavte grafy cez Munin, Zabbix alebo iný systém, ktorý bude logovať: využitie CPU, RAM, dĺžku fronty PHP-FPM, počet aktívnych vs. voľných procesov, priemerný čas requestov a pod. Tieto údaje vám pomôžu dlhodobo doladiť konfiguráciu – napríklad uvidíte, že po nasadení určitej verzie webu stúpla pamäťová náročnosť, tak upravíte max_children. Alebo spozorujete trend, že návštevnosť rastie a počas kampaní idete na hranu kapacity – viete vopred pridať výkon (navýšiť parametre alebo pridať server).
• Testovanie zmien postupne: Ak plánujete výraznejšie zásahy (napr. prechod z dynamic na static režim, alebo navýšenie procesov o +200%), otestujte to najprv buď na staging prostredí, alebo veľmi opatrne na produkcii mimo špičky. Napríklad prepnúť z dynamic na static: Môže to priniesť zlepšenie latencií pri špičke, ale zároveň to znamená, že hneď od štartu pobeží maximum procesov – teda veľká záťaž na RAM a možno aj CPU. Skúste najprv static s konzervatívnym počtom (napr. static + 50% aktuálne bežných procesov). Sledujte, čo to spraví s loadom. Admini často prepnú na static, keď už presne vedia, koľko procesov ich server unesie bez problémov. Static režim nastavujte iba ak máte dostatočnú pamäťovú rezervu – inak riskujete, že v kľudovom stave bude polovica RAM obsadená nečinnými procesmi, čo možno ani nepotrebujete.
• Trvalé ladenie: Výkonové ladenie nie je jednorazová akcia. V ideálnom prípade by ste sa mali k nastaveniam vrátiť vždy, keď sa zmenia podmienky – napr. upgrade PHP verzie (novšie verzie môžu mať iný memory footprint), zmena kódu aplikácie (nasadenie novej funkcionality môže výrazne ovplyvniť záťaž), zmena infraštruktúry (napr. presun DB na iný server uvoľní pamäť pre PHP, takže môžete pridať procesy), alebo nárast návštevnosti. Priebežne kontrolujte metriky a ak vidíte, že napr. max_children nejak pravidelne dosahujete, upravte konfiguráciu.

Ešte jeden tip: ak bojujete s pamäťou a hľadáte každé voľné MB, skontrolujte aj ostatné nastavenia PHP – napr. disabled_functions, nepotrebné moduly rozšírení atď. Niektorí admini dokonca rekompilujú PHP s vyradením nepotrebných modulov, aby znížili veľkosť procesu. To už sú extrémy (a riskantné v produkcii), ale spomenúť to tu môžeme. Reálnejšie je: ak napríklad nevyužívate Xdebug alebo iné rozšírenia na produkcii, uistite sa, že nie sú načítané, lebo zaberajú pamäť. Taktiež modul JIT (Just-In-Time kompilátor, od PHP 8) – ten by mohol teoreticky zrýchliť niektoré CPU-intenzívne úlohy, ale vo webových aplikáciách zvyčajne neprináša významné zlepšenie, skôr pridáva pamäťovú záťaž. Odporúča sa preto JIT v produkcii buď úplne vypnúť, alebo aspoň nastaviť konzervatívne, pokiaľ nemáte špecifický dôvod ho používať. Výkon webov skôr vylepší spomínaný OPcache než JIT.

Záver a ďalšie kroky

Ladenie PHP-FPM je do určitej miery umelecká disciplína – vyžaduje kombináciu znalosti systému, experimentovania a priebežného sledovania výsledkov. V tomto návode sme prešli hlavné oblasti konfigurácie: výber režimu správy procesov (static/dynamic/ondemand) a jeho vplyv na latenciu vs. využitie zdrojov, nastavenie kľúčových parametrov ako pm.max_children a spol., a spôsob, ako ich vypočítať podľa pamäte a zaťaženia servera. Zdôraznili sme, že vždy treba brať do úvahy špecifiká vášho prostredia – iný prístup zvolíte pre malý web na 1 CPU s 2 GB RAM, iný pre veľký server s 32 GB RAM a stovkami návštevníkov naraz. Rovnako sme upozornili na metodiku: robiť zmeny postupne, zálohovať, testovať pod záťažou a sledovať metriky.

Nezabudnite, že všetky tunings sú odporúčania, nie garantované pravdy. Tuning často prebieha iteratívne: upravíte konfiguráciu, nasadíte, pozorujete. Možno odhalíte nový bottleneck inde (napr. databáza nestíha, keď PHP pustíte naplno). Potom príde na rad ladenie databázy, caching vrstvy atď. Výkon webovej aplikácie je len tak silný, ako najslabší článok v reťazi. PHP-FPM je dôležitý článok, ale ak v kóde beží neoptimálna úloha, musíte riešiť aj ju. Preto na ďalšie kroky odporúčame:

• Analyzovať aplikáciu – využite slowlog, profily (Xdebug, Tideways, New Relic) na identifikovanie pomalých častí kódu. Možno zistíte, že stačí pridať index v databáze alebo zapnúť cache na určité dáta a server zrazu zvládne dvojnásobok.
• Sledovať nové verzie PHP: PHP 8.1-8.4 priniesli rôzne optimalizácie. Každá verzia občas mení správanie garbage collection, JIT, a drobnosti, ktoré môžu ovplyvniť memory footprint. Pri prechode napr. z PHP 8.1 na 8.2 si overte, či nepotrebujete mierne doladiť parametre (spravidla rozdiely nie sú veľké, ale napr. nový typ alebo iné interné vylepšenia môžu ovplyvniť využitie pamäte o pár percent). Zdroje k výkonovým novinkám zvyknú byť v Migration Guide danej verzie.
• Bezpečnosť a stabilita: Pri extrémnom ladení na výkon nezanedbajte stabilitu. Napríklad nastaviť pm.max_requests = 0 a pm.static s veľkým počtom procesov dá maximálny výkon, ale ak sa predsa vyskytne memory leak, postupne vám to môže zjesť celú RAM. Alebo vypnutie časových limitov môže spôsobiť, že visí proces celé hodiny na zlej operácii. Nájdite balans medzi výkonom a robustnosťou. Radšej o pár percent nižší výkon, ale server, ktorý sa nezrúti pri prvej anomálii.

Na záver treba povedať: ak vaša konfigurácia funguje stabilne a výkon je dostatočný, nie je nutné ju silou-mocou „tuniť”. Nemeniť to, čo funguje – aj to je zásada. Výkonové ladenie má zmysel, ak narážate na limity alebo chcete predísť budúcim problémom pri raste záťaže. Dobre nastavené PHP-FPM dokáže obslúžiť tisíce paralelných užívateľov na vhodnom hardvéri. Ak však potreby vášho webu prerastú kapacity jedného servera, možno nastal čas zvážiť škálovanie horizontálne (viac serverov s load balancerom) alebo nasadenie kontajnerizácie (Docker/Kubernetes), kde môžete flexibilne pridávať PHP-FPM inštancie podľa záťaže.

Dôležité je priebežne monitorovať a prispôsobovať nastavenia – čo platí dnes, nemusí stačiť zajtra pri inom type prevádzky. Veríme, že tento návod vám poskytol potrebné znalosti a best practices, aby ste mohli nastaviť PHP-FPM optimálne pre PHP 8.1 až 8.4 a ďalej. 

Spýtajte sa nás, radi poradíme

Ak si s niektorými nastaveniami neviete dať rady alebo potrebujete konzultovať optimálnu konfiguráciu pre váš konkrétny projekt, neváhajte sa obrátiť na našu podporu. Sme pripravení pomôcť so správnym nastavením PHP-FPM, ako aj ďalších služieb na vašom serveri, aby váš web bežal čo najrýchlejšie a najspoľahlivejšie. Výkonové ladenie môže byť náročné, ale s odbornou pomocou to určite zvládnete.