{"id":33827,"date":"2025-10-17T09:20:08","date_gmt":"2025-10-17T07:20:08","guid":{"rendered":"https:\/\/www.websupport.sk\/podpora\/?post_type=ht_kb&#038;p=33827"},"modified":"2025-10-17T09:23:54","modified_gmt":"2025-10-17T07:23:54","slug":"ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov","status":"publish","type":"ht_kb","link":"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/","title":{"rendered":"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov"},"content":{"rendered":"\n<p>Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri. <strong>PHP-FPM predstavuje preferovan\u00fd sp\u00f4sob prev\u00e1dzky PHP na modern\u00fdch serveroch<\/strong> &#8211; je flexibilnej\u0161\u00ed na konfigur\u00e1ciu a efekt\u00edvnej\u0161\u00ed pri obsluhe vysok\u00e9ho po\u010dtu po\u017eiadaviek ne\u017e tradi\u010dn\u00fd modul mod_php v<a href=\"https:\/\/tideways.com\/profiler\/blog\/an-introduction-to-php-fpm-tuning\" target=\"_blank\" rel=\"noreferrer noopener\"> Apache<\/a>.&nbsp;<\/p>\n\n\n\n<p>Z\u00e1rove\u0148 v\u0161ak predvolen\u00e9 nastavenia konfigur\u00e1cie PHP-FPM b\u00fdvaj\u00fa konzervat\u00edvne, aby fungovali \u201epre ka\u017ed\u00e9ho\u201c; to znamen\u00e1, \u017ee nevyu\u017e\u00edvaj\u00fa naplno zdroje v\u00fdkonnej\u0161ieho servera. <strong>Bez optimaliz\u00e1cie sa tak m\u00f4\u017eu objavi\u0165 pomal\u00e9 odozvy pri z\u00e1\u0165a\u017ei, vy\u010derpanie dostupn\u00fdch PHP procesov a neefekt\u00edvne vyu\u017eitie CPU, pam\u00e4te \u010di diskov<\/strong>. Laden\u00edm konfigur\u00e1cie dok\u00e1\u017eeme v\u00fdrazne zr\u00fdchli\u0165 obsluhu PHP skriptov, zvl\u00e1dnu\u0165 viac s\u00fabe\u017en\u00fdch pou\u017e\u00edvate\u013eov a pred\u00eds\u0165 pre\u0165a\u017eeniu syst\u00e9mu.<\/p>\n\n\n\n<p><strong>V\u0161eobecn\u00e9 odpor\u00fa\u010dania a z\u00e1lohovanie<\/strong><\/p>\n\n\n\n<p class=\"wp-block-ht-blocks-messages wp-block-hb-message wp-block-hb-message--withicon is-style-alert\">Pred ak\u00fdmko\u013evek z\u00e1sahom do konfigur\u00e1cie si v\u017edy zaistite aktu\u00e1lnu z\u00e1lohu konfigura\u010dn\u00fdch s\u00faborov a overte, \u017ee viete vykona\u0165 obnovu nastaven\u00ed. Optimaliza\u010dn\u00e9 z\u00e1sahy m\u00f4\u017eu vies\u0165 k neo\u010dak\u00e1van\u00fdm probl\u00e9mom &#8211; majte preto pripraven\u00fd pl\u00e1n n\u00e1vratu k p\u00f4vodn\u00e9mu stavu.<\/p>\n\n\n\n<p>Pam\u00e4tajte, \u017ee ni\u017e\u0161ie uveden\u00e9 nastavenia a hodnoty s\u00fa informat\u00edvne odpor\u00fa\u010dania. Ka\u017ed\u00fd server a aplik\u00e1cia m\u00e1 in\u00e9 po\u017eiadavky, preto ladeniu pristupujte met\u00f3dou pokus-omyl s priebe\u017en\u00fdm testovan\u00edm. Odpor\u00fa\u010dan\u00e9 hodnoty treba doladi\u0165 pod\u013ea re\u00e1lnej z\u00e1\u0165a\u017ee a v\u00fdsledkov meran\u00ed.<\/p>\n\n\n\n<p>Z\u00e1kladn\u00e9 pravidlo v\u00fdkonov\u00e9ho ladenia je meni\u0165 v\u017edy iba jednu vec naraz a pozorova\u0165 vplyv. Ak by ste upravili viac parametrov s\u00fa\u010dasne a zlep\u0161il by sa (alebo zhor\u0161il) v\u00fdkon, \u0165a\u017eko zist\u00edte, ktor\u00e1 zmena mala ak\u00fd efekt. Preto postupujte iterat\u00edvne a trpezlivo.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Pre\u010do PHP-FPM? Rozdiely oproti mod_php<\/h2>\n\n\n\n<p>PHP aplik\u00e1cie m\u00f4\u017eeme na webovom serveri <strong>prev\u00e1dzkova\u0165 r\u00f4znymi sp\u00f4sobmi<\/strong>. Historicky roz\u0161\u00edren\u00fd bol najm\u00e4 modul mod_php pre Apache &#8211; PHP sa na\u010d\u00edtalo priamo do procesov webservera. Ka\u017ed\u00e1 prich\u00e1dzaj\u00faca HTTP po\u017eiadavka tak be\u017eala v r\u00e1mci Apache procesu, ktor\u00fd mal do seba vstavan\u00fd <a href=\"https:\/\/www.cloudways.com\/blog\/php-fpm-on-cloud\/\" target=\"_blank\" rel=\"noreferrer noopener\">PHP interpreter<\/a>. Jednoducho povedan\u00e9, Apache s mod_php pri spracovan\u00ed PHP str\u00e1nky spustil nov\u00fd proces (alebo vl\u00e1kno) a inicializoval v \u0148om PHP engine. T\u00e1to met\u00f3da v\u0161ak mala viacer\u00e9 nev\u00fdhody. Musela pou\u017e\u00edva\u0165 tzv. prefork re\u017eim (proces na ka\u017ed\u00e9 spojenie) kv\u00f4li obmedzeniam vl\u00e1kien v PHP, \u010do viedlo k vysokej r\u00e9\u017eii na RAM a CPU pri v\u00e4\u010d\u0161om po\u010dte s\u00fabe\u017en\u00fdch po\u017eiadaviek. Pre ka\u017ed\u00fa po\u017eiadavku sa vlastne znovu \u0161tartoval PHP interpreter, \u010do je samozrejme neefekt\u00edvne.<\/p>\n\n\n\n<p>Naproti tomu <strong>PHP-FPM funguje ako samostatn\u00fd procesov\u00fd mana\u017e\u00e9r<\/strong> na pozad\u00ed. Webov\u00fd server (\u010di u\u017e Apache alebo Nginx) nevybavuje PHP k\u00f3d priamo, ale odo\u0161le ho prostredn\u00edctvom protokolu FastCGI do be\u017eiacej slu\u017eby PHP-FPM. PHP-FPM udr\u017euje <strong>pool worker procesov<\/strong> PHP, ktor\u00e9 s\u00fa dopredu spusten\u00e9 a pripraven\u00e9 spracova\u0165 prich\u00e1dzaj\u00face po\u017eiadavky bez oneskorenia so \u0161tartom procesu. <strong>Webserver teda deleguje PHP spracovanie extern\u00e9mu procesu<\/strong> &#8211; \u201epo\u0161le\u201c skript do PHP-FPM cez socket alebo TCP port a zoberie si v\u00fdsledok. Tento pr\u00edstup prin\u00e1\u0161a viacero v\u00fdhod:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Lep\u0161ia efektivita a v\u00fdkon<\/h3>\n\n\n\n<p>Ke\u010f\u017ee PHP be\u017e\u00ed ako perzistnentn\u00e9 procesy, nie je potrebn\u00e9 pre ka\u017ed\u00fd request \u0161tartova\u0165 nov\u00fd proces s interpreterom ako pri mod_php. To \u0161etr\u00ed \u010das aj <strong>CPU cykly a umo\u017e\u0148uje obsl\u00fa\u017ei\u0165 viac po\u017eiadaviek paralelne<\/strong>. Testy ukazuj\u00fa, \u017ee <strong>stack s PHP-FPM m\u00e1 vy\u0161\u0161iu priepustnos\u0165 a stabilitu<\/strong> oproti mod_php. PHP-FPM je dnes pova\u017eovan\u00fd za r\u00fdchlej\u0161\u00ed a flexibilnej\u0161\u00ed sp\u00f4sob nasadenia PHP aplik\u00e1ci\u00ed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Oddelenie od webservera<\/h3>\n\n\n\n<p><strong>PHP-FPM be\u017e\u00ed nez\u00e1visle<\/strong>, v\u010faka \u010domu mo\u017eno webov\u00fd server (Apache, Nginx) nakonfigurova\u0165 \u00faspornej\u0161ie. Napr\u00edklad Apache m\u00f4\u017ee be\u017ea\u0165 v re\u017eime event\/worker MPM, ktor\u00fd lep\u0161ie \u0161k\u00e1luje (s mod_php musel pou\u017e\u00edva\u0165 pomal\u0161\u00ed prefork). Taktie\u017e je mo\u017en\u00e9 PHP-FPM \u013eahko pou\u017ei\u0165 s Nginxom, ktor\u00fd modul\u00e1rne sp\u00fa\u0161\u0165anie PHP nepodporuje &#8211; Nginx komunikuje s PHP-FPM cez FastCGI socket.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. Flexibiln\u00e1 konfigur\u00e1cia a bezpe\u010dnos\u0165&nbsp;<\/h3>\n\n\n\n<p><strong>PHP-FPM umo\u017e\u0148uje definova\u0165 viacero pool-ov procesov s r\u00f4znymi nastaveniami<\/strong> (in\u00e9 po\u010dty procesov, in\u00fd pou\u017e\u00edvate\u013e\/sk\u00e1 skupina, in\u00e9 php.ini parametre at\u010f.). To je u\u017eito\u010dn\u00e9 pri hostingu viacer\u00fdch aplik\u00e1ci\u00ed &#8211; ka\u017ed\u00e1 m\u00f4\u017ee ma\u0165 vlastn\u00fd pool (pr\u00edpadne be\u017ea\u0165 pod in\u00fdm syst\u00e9mov\u00fdm \u00fa\u010dtom pre zv\u00fd\u0161en\u00fa izol\u00e1ciu). V Apache mod_php re\u017eime v\u0161etko be\u017ealo pod \u00fa\u010dtom webservera a v r\u00e1mci jedn\u00e9ho procesu, \u010do zvy\u0161ovalo riziko konfliktov a komplikovalo ladenie.<\/p>\n\n\n\n<p>Z historick\u00e9ho h\u013eadiska vzniklo PHP-FPM ako patch na PHP cca v roku 2009 s cie\u013eom zlep\u0161i\u0165 spr\u00e1vu procesov a v\u00fdkon pre vysoko nav\u0161tevovan\u00e9 weby. Od PHP 5.3 je u\u017e s\u00fa\u010das\u0165ou ofici\u00e1lneho PHP. V s\u00fa\u010dasnosti je PHP-FPM predvolen\u00fdm sp\u00f4sobom nasadenia PHP na v\u00e4\u010d\u0161ine produk\u010dn\u00fdch serverov, pri\u010dom mod_php sa pova\u017euje za zastaran\u00fd (v nov\u0161\u00edch verzi\u00e1ch distrib\u00faci\u00ed u\u017e \u010dasto ani nie je zahrnut\u00fd).&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Architekt\u00fara PHP-FPM a spr\u00e1va procesov<\/h2>\n\n\n\n<p>Aby sme pochopili ladenie PHP-FPM, pozrime sa stru\u010dne na to, ako PHP-FPM mana\u017euje procesy. PHP-FPM be\u017e\u00ed ako master daemon (proces) <code>php-fpm<\/code>, ktor\u00fd sp\u00fa\u0161\u0165a a riadi viacero worker procesov (tie vykon\u00e1vaj\u00fa samotn\u00fd PHP k\u00f3d). Po \u0161tarte na\u010d\u00edta nastavenia z konfigura\u010dn\u00e9ho s\u00faboru (typicky <code>\/etc\/php\/8.X\/fpm\/php-fpm.conf<\/code> a pool defin\u00edcie v prie\u010dinku <code>pool.d\/<\/code>). Ka\u017ed\u00fd pool predstavuje skupinu procesov obsluhuj\u00facich jednu alebo viac webov\u00fdch lokal\u00edt. Naj\u010dastej\u0161ie existuje aspo\u0148 pool [www], ktor\u00fd obsluhuje webov\u00e9 po\u017eiadavky z default webu. M\u00f4\u017eeme v\u0161ak definova\u0165 vlastn\u00e9 pooly pre r\u00f4zne str\u00e1nky alebo \u010dasti aplik\u00e1cie (napr. frontend vs. backend e-shopu) a odli\u0161ne ich nakonfigurova\u0165.<\/p>\n\n\n\n<p><strong>Komunik\u00e1cia:<\/strong> Webserver (napr. Nginx) posiela po\u017eiadavky na PHP skripty PHP-FPM procesu cez tzv. FastCGI socket (m\u00f4\u017ee to by\u0165 Unix socket s\u00fabor, napr. <code>\/var\/run\/php\/php-fpm.sock<\/code>, alebo sie\u0165ov\u00fd port, napr. <code>127.0.0.1:9000<\/code>). PHP-FPM neust\u00e1le po\u010d\u00fava na tomto sockete. Ke\u010f pr\u00edde po\u017eiadavka, PHP-FPM ju odovzd\u00e1 jedn\u00e9mu zo svojich vo\u013en\u00fdch worker procesov, ktor\u00fd vykon\u00e1 PHP k\u00f3d a vr\u00e1ti v\u00fdsledok (HTML\/JSON at\u010f.) <a href=\"https:\/\/mateusguimaraes.com\/posts\/optimizing-php-applications-for-performance\">webserveru<\/a>. Ak v danom momente nie je \u017eiadny vo\u013en\u00fd worker (v\u0161etky s\u00fa zanepr\u00e1zdnen\u00e9 spracovan\u00edm in\u00fdch po\u017eiadaviek), PHP-FPM sa m\u00f4\u017ee pok\u00fasi\u0165 vytvori\u0165 nov\u00fd proces (ak to povo\u013euje nastavenie) alebo &#8211; ak u\u017e dosiahol strop povolen\u00fdch procesov &#8211; mus\u00ed \u010fal\u0161ie po\u017eiadavky zaradi\u0165 do fronty (alebo odmietnu\u0165). Pr\u00e1ve parametre ur\u010duj\u00face ko\u013eko procesov m\u00f4\u017ee be\u017ea\u0165 a ako sa spr\u00e1va fronta patria k najd\u00f4le\u017eitej\u0161\u00edm pre ladenie v\u00fdkonu.<\/p>\n\n\n\n<p>Na strane webservera je d\u00f4le\u017eit\u00e9 spomen\u00fa\u0165 parameter <strong>listen.backlog<\/strong> v konfigur\u00e1cii PHP-FPM. Ur\u010duje ve\u013ekos\u0165 fronty nevybaven\u00fdch po\u017eiadaviek na sockete &#8211; napr\u00edklad nastavenie <code>listen.backlog = 65535<\/code> zv\u00fd\u0161i kapacitu fronty pre extr\u00e9mne za\u0165a\u017eenie (predvolen\u00e1 hodnota b\u00fdva ni\u017e\u0161ia). Pri vysokom po\u010dte s\u00fabe\u017en\u00fdch spojen\u00ed by pr\u00edli\u0161 mal\u00fd backlog mohol sp\u00f4sobi\u0165 odmietanie nov\u00fdch spojen\u00ed e\u0161te sk\u00f4r, ne\u017e ich PHP-FPM <a href=\"https:\/\/inspector.dev\/best-practices-for-php-fpm-with-high-concurrent-users\/\">stihne prija\u0165<\/a>. Webserver (Nginx) by v takom pr\u00edpade logoval chyby typu <code>\u201cconnect() to unix:\/var\/run\/php-fpm.sock failed (11: Resource temporarily unavailable)\u201d<\/code>, \u010do indikuje pln\u00fd backlog. Preto na vysoko z\u00e1\u0165a\u017eov\u00fdch serveroch zv\u00fd\u0161te listen.backlog (alebo nastavte na -1, \u010do znamen\u00e1 \u201cbez limitu\u201d, resp. pou\u017eitie maxima povolen\u00e9ho syst\u00e9mom).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Re\u017eimy spr\u00e1vy procesov: static, dynamic, ondemand<\/h2>\n\n\n\n<p>PHP-FPM pon\u00faka tri sp\u00f4soby (\u201cprocess manager\u201d re\u017eimy), ak\u00fdmi riadi po\u010det worker procesov. Tento parameter pm m\u00f4\u017ee nadobudn\u00fa\u0165 hodnoty <strong>static<\/strong>, <strong>dynamic<\/strong> alebo <strong>ondemand<\/strong>. Vo\u013eba spr\u00e1vneho re\u017eimu v\u00fdrazne ovplyvn\u00ed v\u00fdkon a spotrebu zdrojov:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Static<\/h3>\n\n\n\n<p>FPM spust\u00ed pevne dan\u00fd po\u010det PHP procesov a udr\u017euje ich st\u00e1le akt\u00edvne. Po\u010det sa nastavuje direkt\u00edvou <code>pm.max_children<\/code>. V re\u017eime static je v\u017edy spusten\u00fd maxim\u00e1lny po\u010det procesov, bez oh\u013eadu na aktu\u00e1lnu z\u00e1\u0165a\u017e . V\u00fdhodou je, \u017ee po\u017eiadavky nikdy nemusia \u010daka\u0165 na \u0161tart nov\u00e9ho procesu &#8211; latencia je minim\u00e1lna. <strong>Ide teda o najr\u00fdchlej\u0161\u00ed pr\u00edstup, vhodn\u00fd pre vysoko n\u00e1v\u0161tevn\u00e9 weby, kde je potrebn\u00e9 okam\u017eite obsl\u00fa\u017ei\u0165 ve\u013ek\u00e9 mno\u017estvo dopytov<\/strong>. Nev\u00fdhodou je <strong>vy\u0161\u0161ia spotreba pam\u00e4te aj pri n\u00edzkej z\u00e1\u0165a\u017ei<\/strong> (ve\u013ea ne\u010dinn\u00fdch procesov zaber\u00e1 RAM) a potenci\u00e1lne plytvanie prostriedkami, ak traffic kol\u00ed\u0161e. Static vyu\u017e\u00edva naplno zdroje servera, preto sa oplat\u00ed len ak ich m\u00e1te dostatok. Na serveroch s dostato\u010dnou RAM a stabilne vysokou n\u00e1v\u0161tevnos\u0165ou prin\u00e1\u0161a re\u017eim static najvy\u0161\u0161iu priepustnos\u0165.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dynamic<\/h3>\n\n\n\n<p><strong>Ide o predvolen\u00fd re\u017eim<\/strong> vo v\u00e4\u010d\u0161ine distrib\u00faci\u00ed. <strong>Po\u010det procesov sa dynamicky prisp\u00f4sobuje z\u00e1\u0165a\u017ei v r\u00e1mci definovan\u00fdch medz\u00ed<\/strong>. Konfigur\u00e1cia obsahuje p\u00e4\u0165 k\u013e\u00fa\u010dov\u00fdch parametrov: <code>pm.max_children<\/code> (maxim\u00e1lny po\u010det procesov), <code>pm.start_servers<\/code> (ko\u013eko procesov spusti\u0165 pri \u0161tarte), <code>pm.min_spare_servers<\/code> (minim\u00e1lny po\u010det vo\u013en\u00fdch &#8211; ne\u010dinn\u00fdch &#8211; procesov, ktor\u00e9 m\u00e1 PHP-FPM v\u017edy udr\u017eiava\u0165), <code>pm.max_spare_servers<\/code> (maxim\u00e1lny po\u010det vo\u013en\u00fdch procesov) a <code>pm.process_idle_timeout<\/code> (doba ne\u010dinnosti, po ktorej sa nadbyto\u010dn\u00fd proces ukon\u010d\u00ed). V dynamickom re\u017eime PHP-FPM v\u017edy udr\u017euje aspo\u0148 pm.min_spare_servers vo\u013en\u00fdch procesov pripraven\u00fdch. Ak pr\u00edde viac po\u017eiadaviek, ne\u017e je moment\u00e1lne procesov, PHP-FPM m\u00f4\u017ee sp\u00fa\u0161\u0165a\u0165 nov\u00e9 procesy (a\u017e k\u00fdm ich celkov\u00fd po\u010det nedosiahne pm.max_children). Naopak, ke\u010f opadne z\u00e1\u0165a\u017e a vo\u013en\u00fdch procesov je viac ne\u017e <code>pm.max_spare_servers<\/code>, nadbyto\u010dn\u00e9 sa ukon\u010dia. <\/p>\n\n\n\n<p><strong>Tento re\u017eim je flexibiln\u00fd &#8211; sna\u017e\u00ed sa ma\u0165 dostatok procesov, ale z\u00e1rove\u0148 neudr\u017euje zbyto\u010dne ve\u013ea ne\u010dinn\u00fdch workers<\/strong>. Je vhodn\u00fd pre v\u00e4\u010d\u0161inu be\u017en\u00fdch aplik\u00e1ci\u00ed s premenliv\u00fdm trafficom. Treba ho v\u0161ak spr\u00e1vne naladi\u0165, aby pri \u0161pi\u010dke st\u00edhal (dostatok <code>max_children<\/code>) a pri n\u00edzkej z\u00e1\u0165a\u017ei zbyto\u010dne \u201ene\u017eral\u201d pam\u00e4\u0165 (primeran\u00e9 spare parametre). Nespr\u00e1vne nastavenie m\u00f4\u017ee vies\u0165 k spr\u00e1vam v logu typu <code>\u201c[pool\u2026] seems busy, spawning children\u2026\u201d<\/code> , \u010do nazna\u010duje, \u017ee PHP-FPM musel \u010dasto dynamicky \u0161tartova\u0165 procesy &#8211; vtedy treba zv\u00fd\u0161i\u0165<code> start_servers<\/code> \u010di <code>min_spare_servers<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Ondemand<\/h3>\n\n\n\n<p><strong>V tomto re\u017eime PHP-FPM procesy nesp\u00fa\u0161\u0165a dopredu v\u00f4bec \u017eiadne<\/strong> (alebo len minimum) a vytv\u00e1ra ich a\u017e ke\u010f pr\u00eddu po\u017eiadavky. Po ur\u010ditom \u010dase ne\u010dinnosti procesy op\u00e4\u0165 ukon\u010d\u00ed. Konfigur\u00e1cia tu pou\u017e\u00edva parametre <code>pm.max_children<\/code> (maxim\u00e1lny povolen\u00fd po\u010det procesov) a <code>pm.process_idle_timeout<\/code> (ko\u013eko sek\u00fand po obsluhe po\u017eiadavky proces \u010dak\u00e1 ne\u010dinn\u00fd, k\u00fdm ho PHP-FPM ukon\u010d\u00ed). Parametre ako <code>start_servers<\/code> \u010di <code>spare_servers<\/code> sa pri ondemand re\u017eime ignoruj\u00fa (nemaj\u00fa zmysel). V\u00fdhodou ondemand je minim\u00e1lna spotreba pam\u00e4te v obdob\u00ed n\u00edzkej alebo nulovej z\u00e1\u0165a\u017ee, preto\u017ee nebe\u017eia \u017eiadne zbyto\u010dn\u00e9 procesy. Hod\u00ed sa to napr\u00edklad pre menej vyu\u017e\u00edvan\u00e9 administr\u00e1torsk\u00e9 rozhrania, alebo pri multihostingu so stovkami webov, z ktor\u00fdch v\u00e4\u010d\u0161ina je v\u00e4\u010d\u0161inu \u010dasu bez n\u00e1v\u0161tevn\u00edkov. <\/p>\n\n\n\n<p><strong>Nev\u00fdhodou m\u00f4\u017ee by\u0165 latencia pri n\u00e1hlom pr\u00edchode novej z\u00e1\u0165a\u017ee. <\/strong>Oneskorenie b\u00fdva pri prvom hite zvy\u010dajne v desiatkach milisek\u00fand (\u010dasto pod ~100 ms) z n\u00e1\u0161ho testovania na modernom hardv\u00e9ri. Tie\u017e \u010dast\u00e9 vytv\u00e1ranie a ni\u010denie procesov mierne zvy\u0161uje re\u017eijn\u00fa z\u00e1\u0165a\u017e a fragment\u00e1ciu pam\u00e4te. <strong>Ondemand teda nie je ide\u00e1lny pre vysok\u00fa prem\u00e1vku, kde neust\u00e1le prich\u00e1dzaj\u00fa po\u017eiadavky<\/strong> &#8211; tam by procesy aj tak nikdy nestihli \u201eodumrie\u0165\u201d a overhead by bol zbyto\u010dn\u00fd.<\/p>\n\n\n\n<p><strong>Vo\u013eba re\u017eimu z\u00e1vis\u00ed od charakteru v\u00e1\u0161ho webu:<\/strong> Pre mal\u00e9 alebo zriedka nav\u0161tevovan\u00e9 str\u00e1nky (napr. intern\u00e9 administr\u00e1cie) je vhodn\u00fd ondemand &#8211; u\u0161etr\u00ed RAM t\u00fdm, \u017ee procesy be\u017eia iba ke\u010f treba. Pou\u017e\u00edvate\u013e ob\u010das toleruje mierne zdr\u017eanie pri preb\u00fadzan\u00ed procesu. Naopak pre vysoko za\u0165a\u017een\u00e9 weby s mno\u017estvom requestov za sekundu (napr. e-shopy, spravodajsk\u00e9 weby) sa odpor\u00fa\u010da static s dostato\u010dne vysok\u00fdm <code>pm.max_children<\/code>, aby boli v\u0161etky po\u017eiadavky okam\u017eite obsl\u00fa\u017een\u00e9. Aj ke\u010f to znamen\u00e1 ve\u013ea ne\u010dinn\u00fdch procesov, d\u00f4le\u017eit\u00e9 je, \u017ee pri \u0161pi\u010dkovom n\u00e1vale nebud\u00fa vznikn\u00fa\u0165 oneskorenia kv\u00f4li sp\u00fa\u0161\u0165aniu procesov a server vyu\u017eije naplno svoju kapacitu. Re\u017eim dynamic predstavuje kompromis a naj\u010dastej\u0161ie sa vyu\u017e\u00edva pri stredne variabilnej z\u00e1\u0165a\u017ei, kde nechceme \u00faplne plytva\u0165 prostriedkami ako static, ale ani riskova\u0165 latencie ako pri ondemand. Pravdupovediac, spr\u00e1vna odpove\u010f na ot\u00e1zku \u201ektor\u00fd re\u017eim je najlep\u0161\u00ed\u201c je z\u00e1vis\u00ed od situ\u00e1cie &#8211; treba zv\u00e1\u017ei\u0165 profil v\u00e1\u0161ho trafficu a mo\u017enosti servera.<\/p>\n\n\n\n<p class=\"wp-block-ht-blocks-messages wp-block-hb-message wp-block-hb-message--withicon is-style-info\">Re\u017eim (a sprievodn\u00e9 parametre) mo\u017eno nastavi\u0165 pre ka\u017ed\u00fd pool samostatne. Pokojne m\u00f4\u017eete na jednom serveri prev\u00e1dzkova\u0165 viac pool-ov, z ktor\u00fdch jeden (napr. pre frontend) p\u00f4jde v re\u017eime static a in\u00fd (napr. pre m\u00e1lo pou\u017e\u00edvan\u00fd backend\/admin) v re\u017eime ondemand. T\u00fdm dosiahnete, \u017ee kritick\u00e1 \u010das\u0165 aplik\u00e1cie m\u00e1 garantovan\u00fd v\u00fdkon a menej d\u00f4le\u017eit\u00e1 \u010das\u0165 \u0161etr\u00ed zdroje, ke\u010f ju nik nevyu\u017e\u00edva.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">D\u00f4le\u017eit\u00e9 parametre konfigur\u00e1cie PHP-FPM<\/h2>\n\n\n\n<p>Pri laden\u00ed v\u00fdkonu PHP-FPM sa zamerajte najm\u00e4 na nasleduj\u00face k\u013e\u00fa\u010dov\u00e9 nastavenia v konfigura\u010dnom s\u00fabore poolu (\u0161tandardne <code>\/etc\/php\/8.x\/fpm\/pool.d\/www.conf<\/code> pre pool menom \u201e<code>www<\/code>\u201c):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>pm.max_children<\/strong>: Maxim\u00e1lny po\u010det PHP procesov (workerov), ktor\u00e9 smie PHP-FPM spusti\u0165. Toto je kritick\u00fd parameter ovplyv\u0148uj\u00faci, ko\u013eko s\u00fabe\u017en\u00fdch PHP po\u017eiadaviek server obsl\u00fa\u017ei. Pri <em>static<\/em> re\u017eime ur\u010duje fixn\u00fd po\u010det procesov. Pri <em>dynamic\/ondemand<\/em> re\u017eime predstavuje horn\u00fa hranicu, ktor\u00fa PHP-FPM neprekro\u010d\u00ed &#8211; ak pr\u00edde viac po\u017eiadaviek ne\u017e je <code>max_children<\/code>, zvy\u0161n\u00e9 musia po\u010dka\u0165 vo fronte (alebo dostan\u00fa chybu 503, ak je fronta pln\u00e1). Nastavenie <code>pm.max_children<\/code> preto mus\u00ed zoh\u013eadni\u0165 hardv\u00e9rov\u00e9 zdroje (najm\u00e4 RAM) a o\u010dak\u00e1van\u00fa \u0161pi\u010dkov\u00fa z\u00e1\u0165a\u017e. Ako ho vypo\u010d\u00edta\u0165 si uk\u00e1\u017eeme v \u010fal\u0161ej \u010dasti.<\/li>\n\n\n\n<li><strong>pm.start_servers<\/strong>: (Len pre <em>dynamic<\/em>) Po\u010det PHP procesov, ktor\u00e9 sa spustia pri \u0161tarte PHP-FPM. Nastavte ho pod\u013ea o\u010dak\u00e1vanej be\u017enej z\u00e1\u0165a\u017ee tak, aby kr\u00e1tko po \u0161tarte nevznikal nedostatok procesov. Be\u017en\u00e9 odpor\u00fa\u010danie je 4 \u00d7 po\u010det CPU jadier, no m\u00f4\u017ee to z\u00e1visie\u0165 aj od pam\u00e4te. Pri na\u0161om uk\u00e1\u017ekovom VPS (4 vCPU, 16 GB RAM) by mohlo d\u00e1va\u0165 zmysel napr\u00edklad ~16-32 procesov pri \u0161tarte (ak o\u010dak\u00e1vame, \u017ee hne\u010f od spustenia p\u00f4jde viac requestov). Pr\u00edli\u0161 vysok\u00e9 \u010d\u00edslo v\u0161ak m\u00f4\u017ee zbyto\u010dne alokova\u0165 pam\u00e4\u0165 pre ne\u010dinn\u00e9 procesy.<\/li>\n\n\n\n<li><strong>pm.min_spare_servers<\/strong>, <strong>pm.max_spare_servers<\/strong>: (Len pre <em>dynamic<\/em>) Minim\u00e1lny a maxim\u00e1lny po\u010det vo\u013en\u00fdch (idle) procesov, ktor\u00e9 PHP-FPM udr\u017euje . Ak po\u010det ne\u010dinn\u00fdch procesov klesne pod min_spare, PHP-FPM vytvor\u00ed nov\u00e9 procesy (pokia\u013e nie je dosiahnut\u00fd <code>max_children<\/code>). Naopak, ak vo\u013en\u00fdch procesov je viac ne\u017e <code>max_spare<\/code>, PHP-FPM niektor\u00e9 ukon\u010d\u00ed. Tieto parametre pom\u00e1haj\u00fa vyhladzova\u0165 v\u00fdkyvy z\u00e1\u0165a\u017ee. Odpor\u00fa\u010dania b\u00fdvaj\u00fa <code>min_spare<\/code> ~ 2 \u00d7 CPU jadr\u00e1 a <code>max_spare<\/code> ~ 4 \u00d7 CPU jadr\u00e1 (resp. rovnak\u00e9 ako <code>start_servers<\/code>) . V praxi: ak m\u00e1te 4-jadrov\u00fd server, sk\u00faste napr. <code>min_spare = 8, max_spare = 16<\/code> (samozrejme v medziach <code>max_children<\/code>). Pri vy\u0161\u0161ej n\u00e1v\u0161tevnosti tieto hodnoty zvy\u0161ujte. Ak v logoch vid\u00edte \u010dast\u00e9 spr\u00e1vy o sp\u00fa\u0161\u0165an\u00ed procesov (<code>\u201cseems busy\u2026 spawning \u2026 children\u201d<\/code>), znamen\u00e1 to, \u017ee <code>min_spare<\/code> je pr\u00edli\u0161 n\u00edzke a PHP-FPM nest\u00edha predv\u00edda\u0165 \u0161pi\u010dku &#8211; zvy\u0161ujte ho. No a naopak, ak m\u00e1te trvalo ve\u013ea ne\u010dinn\u00fdch procesov aj mimo \u0161pi\u010dky, m\u00f4\u017eete <code>max_spare<\/code> zn\u00ed\u017ei\u0165, aby zbyto\u010dn\u00e9 procesy uvo\u013enili pam\u00e4\u0165.<\/li>\n\n\n\n<li><strong>pm.process_idle_timeout<\/strong>: (Pre dynamic aj ondemand) \u010cas v sekund\u00e1ch, ako dlho nech\u00e1 PHP-FPM ne\u010dinn\u00fd proces be\u017ea\u0165 predt\u00fdm, ne\u017e ho ukon\u010d\u00ed. V dynamickom re\u017eime sa takto odstra\u0148uj\u00fa nadbyto\u010dn\u00e9 procesy (ke\u010f ich je viac ne\u017e <code>min_spare<\/code>). V <em>ondemand<\/em> re\u017eime je to k\u013e\u00fa\u010dov\u00fd parameter &#8211; ur\u010duje, ako r\u00fdchlo sa pool \u201cusp\u00ed\u201d pri ne\u010dinnosti. Predvolen\u00e1 hodnota b\u00fdva 10s. M\u00f4\u017eete ju zv\u00fd\u0161i\u0165, ak nechcete pr\u00edli\u0161 agres\u00edvne vyp\u00edna\u0165 procesy (aby sa nere\u0161tartovali priskoro medzi kr\u00e1tkymi burstami trafficu). Naopak, na syst\u00e9moch s obmedzenou RAM m\u00f4\u017eete timeout zn\u00ed\u017ei\u0165, nech sa pam\u00e4\u0165 sk\u00f4r uvo\u013en\u00ed. Napr\u00edklad v cPanel prostred\u00ed s mnoh\u00fdmi webmi defaultne nastavuj\u00fa vy\u0161\u0161\u00ed idle timeout alebo priamo <em>ondemand<\/em> re\u017eim, aby nezahltili RAM ve\u013ek\u00fdm po\u010dtom ne\u010dinn\u00fdch procesov.<\/li>\n\n\n\n<li><strong>pm.max_requests<\/strong>: Maxim\u00e1lny po\u010det po\u017eiadaviek, ktor\u00e9 jeden PHP proces obsl\u00fa\u017ei, k\u00fdm ho PHP-FPM ukon\u010d\u00ed a nahrad\u00ed nov\u00fdm. Predvolen\u00e1 hodnota je 0 (neobmedzene), \u010do znamen\u00e1, \u017ee procesy be\u017eia neust\u00e1le. Nastavenie nenulovej hodnoty (napr. p\u00e1r stoviek) sa odpor\u00fa\u010da, ak va\u0161a aplik\u00e1cia alebo roz\u0161\u00edrenia PHP m\u00f4\u017eu ma\u0165 memory leaky. Postupn\u00e9 zvy\u0161ovanie spotreby pam\u00e4te procesov sa takto \u201evynuluje\u201c ich periodickou recykl\u00e1ciou. V opa\u010dnom pr\u00edpade by dlhodobo be\u017eiaci worker mohol nar\u00e1s\u0165 a ohrozi\u0165 stabilitu. Hodnota 0 (neobmedzene) maximalizuje v\u00fdkon t\u00fdm, \u017ee eliminuje overhead neust\u00e1leho re-spawnovania procesov. Ako v\u017edy, kompromis z\u00e1vis\u00ed od aplik\u00e1cie: ak ste si ist\u00ed, \u017ee \u017eiadne memory leaky nem\u00e1te, m\u00f4\u017eete necha\u0165 <code>pm.max_requests<\/code> vysok\u00e9 (alebo 0). Napr\u00edklad pri pou\u017eit\u00ed re\u017eimu static na v\u00fdkonnom serveri bez memory leakov niektor\u00ed odpor\u00fa\u010daj\u00fa <code>pm.max_requests<\/code> = 0 pre maxim\u00e1lny v\u00fdkon. V opa\u010dnom pr\u00edpade je rozumn\u00e9 nastavi\u0165 napr. 200-500, aby sa procesy raz za \u010das obnovili. Pri ve\u013emi vysokej z\u00e1\u0165a\u017ei a stabilnej aplik\u00e1cii sa osved\u010dilo aj nastavenie vy\u0161\u0161\u00edch hodn\u00f4t (1000+ alebo neobmedzene) na minimaliz\u00e1ciu resetov. Sledujte v\u0161ak spr\u00e1vanie &#8211; ak vid\u00edte rast\u00facu pam\u00e4\u0165 procesu v \u010dase, rad\u0161ej limitujte <code>max_requests<\/code>.<\/li>\n\n\n\n<li><strong>memory_limit (php.ini)<\/strong>: Hoci nejde o parameter PHP-FPM ako tak\u00fd, priamo ovplyv\u0148uje ko\u013eko pam\u00e4te m\u00f4\u017ee jeden PHP proces spotrebova\u0165 (limit pre PHP skript). \u0160tandardne b\u00fdva 128M alebo 256M na proces. Je d\u00f4le\u017eit\u00e9 uvedomi\u0165 si, \u017ee ak nastav\u00edte <code>memory_limit<\/code> ve\u013emi vysoko (napr. 512M \u010di 1G), teoreticky jeden PHP proces m\u00f4\u017ee to\u013eko RAM aj zabra\u0165. To potom drasticky zni\u017euje po\u010det procesov, ktor\u00e9 sa zmestia do pam\u00e4te servera. Pri v\u00fdpo\u010dte <code>pm.max_children<\/code> sa \u010dasto ako hrub\u00fd odhad pou\u017e\u00edva pr\u00e1ve <code>memory_limit<\/code> (alebo e\u0161te lep\u0161ie re\u00e1lna priemern\u00e1 spotreba procesu) . Odpor\u00fa\u010danie je nema\u0165 zbyto\u010dne vysok\u00fd <code>memory_limit<\/code>, iba ak aplik\u00e1cia naozaj sprac\u00fava objemn\u00e9 d\u00e1ta. Pre v\u00e4\u010d\u0161inu webov 128-256 MB posta\u010duje. Tie\u017e zapo\u010d\u00edtate pam\u00e4\u0165 pre OPCache (vi\u010f ni\u017e\u0161ie) &#8211; t\u00e1 sa s\u00edce zdie\u013ea medzi procesmi, ale ukroj\u00ed p\u00e1r stoviek MB z RAM.<\/li>\n\n\n\n<li><strong>max_execution_time<\/strong>, <strong>request_terminate_timeout<\/strong>: Tieto nastavenia (prv\u00e9 v <code>php.ini<\/code>, druh\u00e9 v PHP-FPM conf) ur\u010duj\u00fa, ako dlho smie PHP skript be\u017ea\u0165, k\u00fdm ho ukon\u010d\u00edme. <code>max_execution_time<\/code> je limit na \u00farovni PHP (pre ka\u017ed\u00fd request), <code>request_terminate_timeout<\/code> je tvrd\u00fd limit na \u00farovni PHP-FPM worker procesu. Pri laden\u00ed v\u00fdkonu ich m\u00f4\u017eete nastavi\u0165 vy\u0161\u0161ie, ak viete, \u017ee niektor\u00e9 skripty legit\u00edmne trvaj\u00fa dlh\u0161ie (napr. generovanie reportov), aby neboli pred\u010dasne zabit\u00e9. Na druhej strane, extr\u00e9mne dlh\u00e9 behy skriptov blokuj\u00fa worker proces a zvy\u0161uj\u00fa frontu &#8211; treba zv\u00e1\u017ei\u0165 optimaliz\u00e1ciu tak\u00fdch skriptov alebo ich sp\u00fa\u0161\u0165anie mimo web po\u017eiadavky (cron joby). Typicky sa ponech\u00e1vaj\u00fa defaulty (30s alebo 60s). Pre vysoko konkuren\u010dn\u00e9 prostredie s riskom zaseknutia procesov je vhodn\u00e9 ma\u0165 nastaven\u00fd nejak\u00fd timeout (napr. 300s), aby uviaznut\u00fd proces nezostal visie\u0165 nav\u017edy a nebral zdroje.<\/li>\n\n\n\n<li><strong>OPcache<\/strong>: Jedna z najv\u00e4\u010d\u0161\u00edch \u201cladiacich\u201d v\u00fdhier mimo samotn\u00e9ho PHP-FPM je zapnutie a spr\u00e1vna konfigur\u00e1cia PHP OPcache. Ide o caching mechanizmus, ktor\u00fd uchov\u00e1va skompilovan\u00fd bytecode PHP skriptov v zdie\u013eanej pam\u00e4ti. V\u00fdsledkom je, \u017ee pri opakovanom volan\u00ed toho ist\u00e9ho PHP s\u00faboru sa u\u017e nemus\u00ed znovu parsova\u0165 a kompilova\u0165 do opk\u00f3dov &#8211; skracuje sa vykon\u00e1vanie o tieto kroky. Bez OPcache ka\u017ed\u00fd request \u201eznova\u201d interpretuje PHP k\u00f3d, \u010do plytv\u00e1 CPU aj \u010dasom. Zapnut\u00fd OPcache dramaticky zni\u017euje za\u0165a\u017eenie CPU (v testoch klesol priemer \u010das spracovania PHP aj o 80% ) a z\u00e1rove\u0148 mierne zni\u017euje pam\u00e4\u0165ov\u00fa stopu procesov (ke\u010f\u017ee zdie\u013eaj\u00fa skompilovan\u00fd k\u00f3d). Od PHP 8.0 je OPcache be\u017ene s\u00fa\u010das\u0165ou in\u0161tal\u00e1cie, len ho treba povoli\u0165 v <code>php.ini<\/code> (nastaven\u00edm <code>opcache.enable=1 a opcache.memory_consumption=<\/code>&#8230;). Pre produk\u010dn\u00fd server odpor\u00fa\u010dame OPcache v\u017edy zapn\u00fa\u0165 a nastavi\u0165 mu dostato\u010dne ve\u013ek\u00fa pam\u00e4\u0165 (pod\u013ea ve\u013ekosti v\u00e1\u0161ho k\u00f3du &#8211; napr. 128 MB, 256 MB alebo aj viac pre ve\u013ek\u00e9 aplik\u00e1cie). Sledujte metriky OPcache (vyu\u017eitie vyrovn\u00e1vacej pam\u00e4te) &#8211; ak dosahuje 100% a cache sa prepl\u0148uje, zvy\u0161ujte pam\u00e4\u0165, inak doch\u00e1dza k tzv. cache misses a v\u00fdkon kles\u00e1. Op\u00e4\u0165 v\u0161ak s mierou &#8211; zbyto\u010dne ve\u013ek\u00e1 cache je nevyu\u017eit\u00e1 RAM.<\/li>\n\n\n\n<li><strong>slowlog<\/strong>: PHP-FPM umo\u017e\u0148uje zaznamena\u0165 pomalen\u00e9 skripty &#8211; tie, ktor\u00e9 be\u017eia dlh\u0161ie ne\u017e definovan\u00fd \u010dasov\u00fd limit. Parametre <code>request_slowlog_timeout<\/code> nastavte na prah (v sekund\u00e1ch), po ktorom sa pova\u017euje request za \u201epomal\u00fd\u201c a slowlog ur\u010dite cestu k log s\u00faboru . Napr. m\u00f4\u017eete prida\u0165 do konfigur\u00e1cie pool-u:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-preformatted\">request_slowlog_timeout = 5s<br><br>slowlog = \/var\/log\/php-fpm\/slow.log<\/pre>\n\n\n\n<p>To sp\u00f4sob\u00ed, \u017ee ak nejak\u00fd PHP request be\u017e\u00ed dlh\u0161ie ne\u017e 5 sek\u00fand, PHP-FPM do uveden\u00e9ho s\u00faboru vyp\u00ed\u0161e diagnostiku (vr\u00e1tane backtrace, ak povol\u00edte <code>request_slowlog_trace_depth<\/code>, napr. 20 ). Slowlog je nesmierne u\u017eito\u010dn\u00fd pri laden\u00ed &#8211; pom\u00f4\u017ee v\u00e1m identifikova\u0165, ktor\u00e9 PHP skripty alebo funkcie zdr\u017euj\u00fa spracovanie. M\u00f4\u017eete tak zisti\u0165, \u017ee v\u00e1s brzd\u00ed napr\u00edklad pomal\u00e9 volanie datab\u00e1zy, extern\u00e1 API alebo neefekt\u00edvny algoritmus. Optimaliz\u00e1cia k\u00f3du je \u010dasto najlep\u0161\u00edm liekom na v\u00fdkonov\u00e9 probl\u00e9my, ktor\u00e9 \u017eiadne ldenie PHP-FPM neodstr\u00e1ni. Nezabudnite v\u0161ak rie\u0161i\u0165 rotovanie tohto logu (napr. cez logrotate), aby sa \u010dasom nezaplnil disk .<br><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>listen.mode<\/strong>, <strong>owner,<\/strong> <strong>group<\/strong>: Tieto parametre ur\u010duj\u00fa pr\u00e1va socketu, ak pou\u017e\u00edvate Linux socket na prepojenie s webserverom. Z v\u00fdkonov\u00e9ho h\u013eadiska s\u00fa irelevantn\u00e9, ale spomenieme ich &#8211; ak men\u00edte u\u017e\u00edvate\u013ea, pod ktor\u00fdm PHP-FPM procesy be\u017eia (user\/group direkt\u00edvy poolu), upravte aj <code>listen.owner<\/code> a <code>listen.group<\/code>, aby socket mal spr\u00e1vne opr\u00e1vnenia. <code>listen.backlog <\/code>sme u\u017e spom\u00ednali vy\u0161\u0161ie (vi\u010f architekt\u00fara).<\/li>\n\n\n\n<li><strong>rlimit_files<\/strong>, <strong>rlimit_core<\/strong>: T\u00fdkaj\u00fa sa limitov OS &#8211; max. po\u010det s\u00faborov\u00fdch descriptorov a generovanie core dump s\u00faborov. Pre vysok\u00fa z\u00e1\u0165a\u017e m\u00f4\u017ee by\u0165 potrebn\u00e9 zv\u00fd\u0161i\u0165 <code>rlimit_files<\/code>, ak vid\u00edte chyby typu <code>\u201ctoo many open files\u201d<\/code>. Nastavenie napr. <code>rlimit_files = 65535<\/code> zdvihne limit na po\u010det otvoren\u00fdch s\u00faborov\/s\u00faborov\u00fdch descriptorov pre PHP-FPM proces . To m\u00f4\u017ee zah\u0155\u0148a\u0165 sie\u0165ov\u00e9 sockety, otvoren\u00e9 logy, at\u010f. <code>rlimit_core = unlimited<\/code> povo\u013euje vytvorenie core dumpu pri p\u00e1de procesu (u\u017eito\u010dn\u00e9 pre debug, inak nepotrebn\u00e9). Tieto nastavenia s\u00fa volite\u013en\u00e9 a v\u00e4\u010d\u0161inou netreba meni\u0165, pokia\u013e explicitne nenaraz\u00edte na pr\u00edslu\u0161n\u00e9 limity.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">V\u00fdpo\u010det optim\u00e1lneho po\u010dtu procesov a pam\u00e4\u0165ov\u00e9 n\u00e1roky<\/h2>\n\n\n\n<p>Hodnota <code>pm.max_children<\/code> z\u00e1sadne ovplyv\u0148uje pam\u00e4\u0165ov\u00e9 n\u00e1roky PHP-FPM. Ka\u017ed\u00fd PHP proces zaber\u00e1 ur\u010dit\u00fa pam\u00e4\u0165 (vyhraden\u00fa aj zdie\u013ean\u00fa). Cie\u013eom je vyu\u017ei\u0165 dostupn\u00fa RAM efekt\u00edvne, no nepresiahnu\u0165 ju. Ak nastav\u00edte prive\u013ea procesov, m\u00f4\u017eu zaplni\u0165 RAM a syst\u00e9m za\u010dne swapova\u0165 (\u010do drasticky spomal\u00ed server), alebo v hor\u0161om pr\u00edpade OOM killer za\u010dne zab\u00edja\u0165 procesy. Naopak pr\u00edli\u0161 n\u00edzka hodnota nech\u00e1 nevyu\u017eit\u00fa pam\u00e4\u0165 a obmedz\u00ed po\u010det s\u00fabe\u017en\u00fdch requestov, ktor\u00e9 zvl\u00e1dnete.<\/p>\n\n\n\n<p><strong>Z\u00e1kladn\u00fd postup v\u00fdpo\u010dtu<\/strong>: Zistite, ko\u013eko pam\u00e4te priemerne zaber\u00e1 jeden PHP-FPM proces vo va\u0161ej z\u00e1\u0165a\u017ei a vyde\u013ete dostupn\u00fa pam\u00e4\u0165 touto <a href=\"https:\/\/cino.io\/2019\/optimizing-php-fpm\/\" target=\"_blank\" rel=\"noreferrer noopener\">ve\u013ekos\u0165ou<\/a>. T\u00fdm dostanete hrub\u00fd odhad maxim\u00e1lneho mo\u017en\u00e9ho po\u010dtu procesov. Napr\u00edklad, ak jeden proces potrebuje ~60 MB a m\u00e1te pre PHP k dispoz\u00edcii ~600 MB RAM, teoreticky by ste mohli ma\u0165 a\u017e 10 procesov (600\/60). Samozrejme, nechceme \u00eds\u0165 na doraz &#8211; v\u017edy nechajte rezervu pre OS a in\u00e9 slu\u017eby (webserver, datab\u00e1za at\u010f.) a tie\u017e pre v\u00fdkyvy. <strong>\u010casto sa odpor\u00fa\u010da ponecha\u0165 20-30 % RAM vo\u013enej ako buffer<\/strong>. Rovnako r\u00e1tajte s t\u00fdm, \u017ee nie ka\u017ed\u00fd proces v\u017edy vy\u0165a\u017e\u00ed <code>maximum memory_limit<\/code> &#8211; priemer m\u00f4\u017ee by\u0165 v\u00fdrazne ni\u017e\u0161\u00ed ne\u017e limit, pokia\u013e ve\u013ea requestov rob\u00ed len mal\u00e9 \u00falohy.<\/p>\n\n\n\n<p>Ako zisti\u0165 ve\u013ekos\u0165 procesu? M\u00f4\u017eete vyu\u017ei\u0165 napr\u00edklad skript <a href=\"https:\/\/github.com\/pixelb\/ps_mem\" target=\"_blank\" rel=\"noreferrer noopener\">ps_mem.py<\/a> alebo pr\u00edkaz ps\/top. Pr\u00edklad:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"># Vypo\u010d\u00edta priemern\u00fa RSS pam\u00e4\u0165 PHP-FPM procesov<br><br>ps --no-headers -o \"rss,cmd\" -C php-fpm8.1 | awk '{ sum+=$1 } END { printf (\"%dM\\n\", sum\/NR\/1024) }'<\/pre>\n\n\n\n<p>Tento pr\u00edkaz spo\u010d\u00edta Resident Set Size (RSS) &#8211; re\u00e1lne obsaden\u00fa fyzick\u00fa pam\u00e4\u0165 &#8211; PHP procesov a d\u00e1 priemer. Povedzme, \u017ee v\u00fdsledok je ~50 MB na proces. Ak n\u00e1\u0161 server m\u00e1 16 GB RAM a okrem PHP na \u0148om be\u017e\u00ed u\u017e len OS a webserver, m\u00f4\u017eeme napr. rezervova\u0165 2-4 GB pre syst\u00e9m a zvy\u0161n\u00fdch ~12-14 GB pre PHP-FPM. Pri 50 MB\/proces by teoretick\u00e9 maximum bolo 240-280 procesov. Z toho vezmeme napr\u00edklad 80 % (nech\u00e1me 20 % rezervu) &#8211; \u010di\u017ee okolo 190-220 procesov by mohol syst\u00e9m utiahnu\u0165<\/p>\n\n\n\n<p>V praxi by sme zvolili konzervat\u00edvnej\u0161ie, povedzme<code> pm.max_children<\/code> = 150 (\u010do je asi 7.5 GB pri 50 MB\/proces). Postupne m\u00f4\u017eeme ladi\u0165: sledova\u0165 vy\u0165a\u017eenos\u0165 a pr\u00edpadne zvy\u0161ova\u0165, ak je pam\u00e4\u0165 st\u00e1le vo\u013en\u00e1 a s\u00fa\u010dasne vid\u00edme, \u017ee by sa zi\u0161lo viac paraleln\u00fdch procesov (napr. fronta po\u017eiadaviek v stave <em>Waiting<\/em>). Nikdy neza\u010d\u00ednajte extr\u00e9mne vysoko &#8211; rad\u0161ej postupne prid\u00e1vajte, inak riskujete p\u00e1d servera pri \u0161pi\u010dke.<\/p>\n\n\n\n<p>Pre n\u00e1\u0161 konkr\u00e9tny pr\u00edklad VPS s 4 vCPU a 16 GB RAM si uk\u00e1\u017eeme orienta\u010dn\u00fd v\u00fdpo\u010det. Predpokladajme, \u017ee be\u017e\u00ed len webov\u00fd server a PHP (datab\u00e1za je na inom stroji, tak\u017ee v\u00e4\u010d\u0161inu pam\u00e4te m\u00f4\u017eeme da\u0165 PHP). OS a demonov (SSH, syslog at\u010f.) nech\u00e1me ~2 GB, \u010di\u017ee zost\u00e1va ~14 GB pre PHP-FPM. Ko\u013eko zaber\u00e1 proces? Z\u00e1le\u017e\u00ed od aplik\u00e1cie &#8211; jednoduch\u00fd WordPress m\u00f4\u017ee bra\u0165 30-50 MB na request, robustn\u00fd e-shop aj 100+ MB. Ak nastav\u00edme <code>memory_limit = 256M<\/code>, neznamen\u00e1 to, \u017ee ka\u017ed\u00fd proces to\u013eko aj zoberie, ale mal by ma\u0165 t\u00fa mo\u017enos\u0165. Pre hrub\u00fd odhad zoberme napr. 128 MB na proces (to u\u017e pokryje aj n\u00e1ro\u010dnej\u0161ie skripty). (14 GB dostupn\u00fdch) \/ (128 MB) = 112 procesov. Odpor\u00fa\u010danie je nevyu\u017ei\u0165 v\u0161etko, ale tak ~75-80 %. 80 % zo 112 je ~90 procesov. <\/p>\n\n\n\n<p>M\u00f4\u017eeme teda nastavi\u0165 <code>pm.max_children = 90 <\/code>ako \u0161tartovac\u00ed bod. Na\u0161e CPU (4 jadr\u00e1) zvl\u00e1dnu 90 paraleln\u00fdch vl\u00e1kien len v pr\u00edpade, \u017ee v\u00e4\u010d\u0161ina z nich ne\u010dak\u00e1 na CPU (napr. \u010dakaj\u00fa na I\/O). To je re\u00e1lny scen\u00e1r &#8211; pri webov\u00fdch aplik\u00e1ci\u00e1ch mnoh\u00e9 procesy \u010dakaj\u00fa na odpove\u010f DB, diskov\u00e9 oper\u00e1cie, sie\u0165 at\u010f., tak\u017ee viac procesov ne\u017e jadier d\u00e1va zmysel. Ak by v\u0161ak va\u0161a aplik\u00e1cia bola extr\u00e9mne CPU n\u00e1ro\u010dn\u00e1 (vedeck\u00e9 v\u00fdpo\u010dty v PHP a pod.), tak by 90 simult\u00e1nnych behov pre\u0165a\u017eilo CPU &#8211; v takom pr\u00edpade by ste volili \u010d\u00edslo bli\u017e\u0161ie po\u010dtu jadier (napr. 8 procesov na 4 jadra, \u010do umo\u017en\u00ed hyperthreading). Pre drviv\u00fa v\u00e4\u010d\u0161inu webov je v\u0161ak bottleneck inde ne\u017e \u010dist\u00fd CPU, preto nastavenie vy\u0161\u0161ieho po\u010dtu procesov umo\u017en\u00ed lep\u0161ie vyu\u017ei\u0165 \u010das, ke\u010f procesy \u010dakaj\u00fa.<\/p>\n\n\n\n<p>Na\u0161e zvolen\u00e9 <code>pm.max_children = 90<\/code> \u010falej dolad\u00edme parametrami pre <em>dynamic<\/em> re\u017eim. Povedzme, \u017ee zvol\u00edme <code>pm = dynamic<\/code> (rozumn\u00e9 pre za\u010diatok). Pod\u013ea odpor\u00fa\u010dan\u00ed nastav\u00edme: <code>pm.start_servers = 8<\/code> (2 \u00d7 vCPU alebo ~10 % z max_children), <code>pm.min_spare_servers = 8<\/code>, <code>pm.max_spare_servers = 20<\/code>. \u010ci\u017ee pri \u0161tarte pobe\u017e\u00ed 8 procesov a v rezerve budeme dr\u017ea\u0165 8-20 vo\u013en\u00fdch pod\u013ea potreby. Konfigur\u00e1cia by mohla vyzera\u0165 napr\u00edklad takto:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">pm = dynamic<br><br>pm.max_children = 90<br><br>pm.start_servers = 8<br><br>pm.min_spare_servers = 8<br><br>pm.max_spare_servers = 20<br><br>pm.max_requests = 500<\/pre>\n\n\n\n<p>(Uv\u00e1dzame <code>pm.max_requests = 500<\/code> ako ur\u010dit\u00fa poistku pred leakmi &#8211; konkr\u00e9tna hodnota z\u00e1vis\u00ed od aplik\u00e1cie.) Tak\u00e1to konfigur\u00e1cia by mala zabezpe\u010di\u0165 stabilitu pri vysokom po\u010dte s\u00fabe\u017en\u00fdch u\u017e\u00edvate\u013eov, pri\u010dom nevy\u010derp\u00e1 \u00faplne 16 GB RAM. Samozrejme, skuto\u010dn\u00fd ide\u00e1l m\u00f4\u017ee by\u0165 in\u00fd &#8211; mus\u00edme to otestova\u0165.<\/p>\n\n\n\n<p><strong>Automatizovan\u00e9 n\u00e1stroje<\/strong>: Existuj\u00fa kalkula\u010dky a skripty, ktor\u00e9 v\u00e1m vygeneruj\u00fa odpor\u00fa\u010dan\u00e9 nastavenia na z\u00e1klade parametrov servera. Napr\u00edklad online n\u00e1stroj <a href=\"https:\/\/spot13.com\/pmcalculator\/\" target=\"_blank\" rel=\"noreferrer noopener\">Spot13 PM Calculator<\/a> umo\u017e\u0148uje zada\u0165 celkov\u00fa RAM, rezervovan\u00fa RAM, percento bufferu a ve\u013ekos\u0165 procesu &#8211; a vypo\u010d\u00edta hodnoty <code>max_children, start\/min\/max_spare<\/code>. \u010ealej je tu skript <a href=\"https:\/\/github.com\/samdark\/php-fpm_tuner\" target=\"_blank\" rel=\"noreferrer noopener\">php-fpm_tuner<\/a>. Ke\u010f ho spust\u00edte na be\u017eiacom serveri, prepo\u010d\u00edta odpor\u00fa\u010dania pod\u013ea aktu\u00e1lne vo\u013enej pam\u00e4te a re\u00e1lnej ve\u013ekosti PHP procesov. V\u00fdstup napr\u00edklad:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">pm.max_children = 11<br>  <br>pm.start_servers = 3<br>  <br>pm.min_spare_servers = 3<br>  <br>pm.max_spare_servers = 8<\/pre>\n\n\n\n<p>Tak\u00fdto n\u00e1stroj je u\u017eito\u010dn\u00fd na prv\u00e9 nastrelenie hodn\u00f4t, ale berte ho s rezervou. Nevid\u00ed \u0161pecifik\u00e1 va\u0161ej aplik\u00e1cie ani \u0161pi\u010dky trafficu. Preto v\u00fdsledky zo skriptu v\u017edy overujte v praxi a kombinujte s vlastn\u00fdm monitoringom.<\/p>\n\n\n\n<p><strong>Napokon, pri nastavovan\u00ed po\u010dtu procesov nezab\u00fadajte na in\u00e9 slu\u017eby<\/strong>. Ak na tom istom serveri be\u017e\u00ed napr. datab\u00e1za MySQL, treba jej necha\u0165 dostatok RAM (MySQL si vie z RAM vzia\u0165 aj nieko\u013eko GB). V takom pr\u00edpade nem\u00f4\u017eete v\u0161etku vo\u013en\u00fa pam\u00e4\u0165 nasadi\u0165 na PHP. Pri na\u0161om pr\u00edklade 16 GB VPS by be\u017eiaca MySQL s cache zaberala povedzme 4-6 GB, syst\u00e9m 2 GB, zostane 8-10 GB pre PHP &#8211; \u010di\u017ee <code>max_children<\/code> by sme \u00famerne zn\u00ed\u017eili (napr. na ~50-60). V\u017edy myslite na cel\u00fd stack, nielen PHP samotn\u00e9.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Monitorovanie v\u00fdkonu a ladenie konfigur\u00e1cie<\/h2>\n\n\n\n<p>Po aplikovan\u00ed zmien v konfigur\u00e1cii (a re\u0161tarte slu\u017eby PHP-FPM) je nevyhnutn\u00e9 sledova\u0165 spr\u00e1vanie servera. <strong>Performance tuning nekon\u010d\u00ed \u00fapravou s\u00faborov<\/strong> &#8211; mus\u00edme overi\u0165, \u010di zmeny priniesli zlep\u0161enie a <strong>\u010di nevznikli nov\u00e9 probl\u00e9my<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Kontrola logov&nbsp;<\/h3>\n\n\n\n<p>Sledujte PHP-FPM error log (typicky <code>\/var\/log\/php8.x-fpm.log<\/code>). H\u013eadajte varovania ako <code>\u201cserver reached pm.max_children setting, consider raising it\u201d<\/code>  &#8211; to zna\u010d\u00ed, \u017ee ste narazili na limit a po\u017eiadavky museli \u010daka\u0165 alebo boli odmietnut\u00e9. Ak tak\u00e9 hl\u00e1senia vid\u00edte \u010dasto a z\u00e1rove\u0148 m\u00e1te e\u0161te vo\u013en\u00fa RAM, je na mieste zv\u00fd\u0161i\u0165 <code>pm.max_children<\/code>. \u010ealej spr\u00e1vy o sp\u00fa\u0161\u0165an\u00ed\/kille procesov v dynamickom re\u017eime: <code>\u201c\u2026 seems busy, spawning \u2026\u201d<\/code>, <code>\u201c\u2026 killing spare child \u2026\u201d<\/code> prezradia, \u010di nastavenia <code>min\/max_spare<\/code> s\u00fa primeran\u00e9. Tie ob\u010dasn\u00e9 z\u00e1znamy s\u00fa norm\u00e1lne, ale ak vid\u00edte neust\u00e1le spawnovanie procesov, mo\u017eno m\u00e1te <code>start_servers<\/code> alebo spare prahy primal\u00e9. Naopak, ak \u010dasto killuje spares, mo\u017eno ich m\u00e1te prive\u013ea &#8211; ale to nie je kritick\u00fd probl\u00e9m, sk\u00f4r znak, \u017ee by sa dalo trochu pam\u00e4\u0165 ubra\u0165.<\/p>\n\n\n\n<p>Ak pou\u017e\u00edvate <code>slowlog<\/code>, analyzujte ho. Ka\u017ed\u00fd z\u00e1znam slowlogu znamen\u00e1 request, ktor\u00fd be\u017eal nad stanoven\u00fd limit (napr. 5s). Sk\u00faste zisti\u0165, pre\u010do &#8211; ak je to neopodstatnen\u00e9 (napr. zle nap\u00edsan\u00e1 SQL query), rie\u0161en\u00edm je optimaliz\u00e1cia k\u00f3du \u010di datab\u00e1zy, nie \u00faprava PHP-FPM. Cie\u013eom ladenia je aj identifikova\u0165 u\u017e\u0161ie miesta aplik\u00e1cie (bottlenecks). PHP-FPM parametre pom\u00f4\u017eu zv\u00fd\u0161i\u0165 priepustnos\u0165, ale ak m\u00e1te jeden skript, ktor\u00fd v\u017edy be\u017e\u00ed 30 sek\u00fand, tak 100 paraleln\u00fdch procesov v\u00e1m akur\u00e1t vy\u0165a\u017e\u00ed CPU a datab\u00e1zu, ale odpove\u010f aj tak potrv\u00e1 30 sek\u00fand &#8211; to mus\u00edte rie\u0161i\u0165 inak (napr. optimalizova\u0165 algoritmus, rozdeli\u0165 \u00falohu, cachova\u0165 v\u00fdsledky at\u010f.).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Sledovanie syst\u00e9mov\u00fdch zdrojov&nbsp;<\/h3>\n\n\n\n<p>Pomocou n\u00e1strojov ako <code>htop <\/code>\u010di <code>top <\/code>sledujte vyu\u017eitie CPU, pam\u00e4te a swapu. V ide\u00e1lnom pr\u00edpade po vyladen\u00ed uvid\u00edte, \u017ee CPU je vyu\u017eit\u00e9 povedzme na 70 % pri \u0161pi\u010dke (predt\u00fdm mo\u017eno nest\u00edhalo alebo naopak bolo nevyu\u017eit\u00e9) a pam\u00e4\u0165 je vyu\u017eit\u00e1 napr. na 80 % bez swapovania. Ak za\u010dnete swapova\u0165 (v\u00fdrazn\u00fd n\u00e1rast IO, syst\u00e9mov\u00e1 RAM 100% pln\u00e1 a obsaden\u00fd swap), to je \u010derven\u00e1 kontrolka &#8211; pr\u00edli\u0161 ve\u013ea procesov alebo pr\u00edli\u0161 ve\u013ek\u00fd <code>memory_limit<\/code>. Okam\u017eite zasiahnu\u0165 (zn\u00ed\u017ei\u0165<code> pm.max_children<\/code> alebo prida\u0165 pam\u00e4\u0165). Tie\u017e sledujte po\u010det be\u017eiacich procesov PHP-FPM v re\u00e1lnom \u010dase &#8211; bu\u010f cez <code>ps\/pgrep<\/code>, alebo si m\u00f4\u017eete povoli\u0165 <a href=\"https:\/\/www.php.net\/manual\/en\/fpm.status.php\" target=\"_blank\" rel=\"noreferrer noopener\">status str\u00e1nku PHP-FPM<\/a>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. PHP-FPM status page&nbsp;<\/h3>\n\n\n\n<p>V konfigur\u00e1cii pool-u viete aktivova\u0165<code> pm.status_path<\/code>, napr\u00edklad <code>pm.status_path = \/fpm_status<\/code>. Ke\u010f potom po\u017eiadate webserver (napr. <code>curl http:\/\/localhost\/fpm_status<\/code> v Nginx, pod\u013ea nastaven\u00e9ho location), PHP-FPM vr\u00e1ti textov\u00fd preh\u013ead: aktu\u00e1lny po\u010det procesov (idle\/busy), nastavene limity a pr\u00edpadne d\u013a\u017eku fronty. Je to ve\u013emi u\u017eito\u010dn\u00e9 na zistenie, \u010di m\u00e1te ve\u013ea vo\u013en\u00fdch procesov alebo naopak \u010dasto v\u0161etky busy a requesty vo fronte. Metriku max children reached (ko\u013ekokr\u00e1t bol dosiahnut\u00fd limit) tam tie\u017e n\u00e1jdete. <strong>Pri laden\u00ed odpor\u00fa\u010dame do\u010dasne povoli\u0165 status<\/strong> (m\u00f4\u017eete ho zabezpe\u010di\u0165 napr. IP adresou alebo heslom, aby nebol verejn\u00fd) a pozera\u0165, \u010do ukazuje po\u010das z\u00e1\u0165a\u017eov\u00fdch testov \u010di re\u00e1lnej prem\u00e1vky.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4. Z\u00e1\u0165a\u017eov\u00e9 testovanie (stress test)&nbsp;<\/h3>\n\n\n\n<p>Ak je to mo\u017en\u00e9, vykonajte testy v\u00fdkonnosti mimo produk\u010dnej \u0161pi\u010dky alebo na testing prostred\u00ed. M\u00f4\u017eete pou\u017ei\u0165 n\u00e1stroje ako Apache Bench (ab), wrk, JMeter, \u010di dokonca jednoduch\u00fd skript vo curl slu\u010dke, ktor\u00fd po\u0161le X paraleln\u00fdch po\u017eiadaviek na v\u00e1\u0161 server. <strong>Simulujte re\u00e1lny scen\u00e1r<\/strong> &#8211; pozor na cache! Ak m\u00e1te HTTP cache (napr. str\u00e1nka generuje statick\u00fd obsah do cache) alebo CDN, otestujte aj cache MISS scen\u00e1re. Be\u017en\u00e1 chyba je vyladi\u0165 PHP-FPM na ke\u0161ovan\u00e9 str\u00e1nky (ktor\u00e9 PHP takmer neza\u0165a\u017eia) a potom pri re\u00e1lnej prev\u00e1dzke na neke\u0161ovan\u00e9 requesty server padne. <\/p>\n\n\n\n<p>Po\u010das testu sledujte metriky: latencie odpoved\u00ed (\u010di nest\u00fapaj\u00fa pri z\u00e1\u0165a\u017ei), vyu\u017eitie CPU\/RAM, logy. Sk\u00faste z\u00e1\u0165a\u017e postupne zvy\u0161ova\u0165. Ak napr. pri 50 paraleln\u00fdch u\u017e\u00edvate\u013eoch je v\u0161etko OK, ale pri 200 u\u017e za\u010dne st\u00fapa\u0165 response time alebo objavia sa chyby 502\/503, viete, kde asi m\u00e1te strop. Vtedy mo\u017eno treba prida\u0165 procesy (ak je e\u0161te pam\u00e4\u0165) alebo ide o limit CPU a pomohlo by \u0161k\u00e1lovanie na viac jadier. Z\u00e1\u0165a\u017eov\u00e9 testy pom\u00f4\u017eu overi\u0165 stabilitu &#8211; ak PHP-FPM pad\u00e1 alebo sa zadrh\u00e1va pri vysokom po\u010dte requestov, rad\u0161ej to odha\u013ete testom, ne\u017e aby v\u00e1s to zasko\u010dilo v ostrej prev\u00e1dzke.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5. Jemn\u00e9 dola\u010fovanie&nbsp;<\/h3>\n\n\n\n<p>Na z\u00e1klade pozorovan\u00ed m\u00f4\u017eete konfigur\u00e1ciu \u010falej dola\u010fova\u0165. Napr\u00edklad: ak vid\u00edte, \u017ee m\u00e1te st\u00e1le &gt;30 % vo\u013enej RAM aj pri \u0161pi\u010dke a fronta requestov sa ob\u010das tvor\u00ed, sk\u00faste zv\u00fd\u0161i\u0165 <code>pm.max_children<\/code> o 10-20 % a znova testova\u0165. Alebo ak vid\u00edte, \u017ee nikdy nem\u00e1te viac ne\u017e 50 akt\u00edvnych procesov, pokojne m\u00f4\u017eete zn\u00ed\u017ei\u0165 <code>max_children<\/code> a u\u0161etri\u0165 pam\u00e4\u0165 pre in\u00e9 \u00fa\u010dely. Tie\u017e sledujte CPU load pri <em>statickom<\/em> vs. <em>dynamickom<\/em> re\u017eime: Niektor\u00ed spr\u00e1vcovia zaznamenali, \u017ee pri <em>static<\/em> re\u017eime je CPU z\u00e1\u0165a\u017e plynulej\u0161ia a pri dynamickom kol\u00ed\u0161e viac (kv\u00f4li spawn\/kill procesov). Ak load average ve\u013emi sk\u00e1\u010de a CPU ob\u010das ide do 100 %, <em>static<\/em> by mohol pom\u00f4c\u0165 &#8211; samozrejme ak m\u00e1te pam\u00e4\u0165. Naopak, ak CPU je v\u00e4\u010d\u0161inu \u010dasu n\u00edzko a pam\u00e4\u0165 je kritick\u00e1, <em>dynamic\/ondemand<\/em> u\u0161etr\u00ed p\u00e1r percent v\u00fdkonu v\u00fdmenou za v\u00fdrazn\u00fa \u00fasporu RAM.<\/p>\n\n\n\n<p>Pri laden\u00ed v\u00fdkonu sa ob\u010das pou\u017e\u00edva technika \u201evybudenia\u201d syst\u00e9mu &#8211; z\u00e1\u0165a\u017eov\u00fd test s postupn\u00fdm zvy\u0161ovan\u00edm intenzity a\u017e k\u00fdm sa neobjavia prv\u00e9 probl\u00e9my. Zist\u00edte tak bod zlomu (break point). Napr. testujte so 100, 200, 300 paraleln\u00fdmi po\u017eiadavkami\u2026 a\u017e pri 300 za\u010dn\u00fa time-outy. To ukazuje, \u017ee konfigur\u00e1cia zvl\u00e1da ~250 concurrency, ale 300 u\u017e nie. Potom bu\u010f zlep\u0161\u00edte konfigur\u00e1ciu (ak s\u00fa rezervy), alebo viete, \u017ee fyzicky ten stroj viac nezvl\u00e1dne a museli by ste \u0161k\u00e1lova\u0165 horizont\u00e1lne (viac serverov za loadbalancer) \u010di vertik\u00e1lne (v\u00fdkonnej\u0161\u00ed server). Ladenie PHP-FPM m\u00e1 svoje limity &#8211; ak naraz\u00edte na strop dan\u00fd HW, \u010fal\u0161ie zvy\u0161ovanie parametrov nepom\u00f4\u017ee a m\u00f4\u017ee u\u0161kodi\u0165.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Viacero pool-ov a oddelenie slu\u017eieb<\/h2>\n\n\n\n<p>Ako u\u017e bolo spomenut\u00e9, PHP-FPM umo\u017e\u0148uje definova\u0165 viac pool-ov procesov. Ka\u017ed\u00fd pool funguje ako samostatn\u00e1 skupina PHP procesov s vlastn\u00fdm nastaven\u00edm. V praxi toho vyu\u017eijete v t\u00fdchto scen\u00e1roch:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Oddelenie r\u00f4znych webov\u00fdch aplik\u00e1ci\u00ed na jednom serveri&nbsp;<\/h3>\n\n\n\n<p>Ak hostujete viac webov, odpor\u00fa\u010da sa ka\u017ed\u00e9mu vyhradi\u0165 vlastn\u00fd PHP-FPM pool (\u010dasto aj be\u017eiaci pod in\u00fdm syst\u00e9mov\u00fdm u\u017e\u00edvate\u013eom kv\u00f4li bezpe\u010dnosti). V\u00fdhody s\u00fa: lep\u0161ia izol\u00e1cia (p\u00e1d alebo zahltenie jedn\u00e9ho poolu nezhod\u00ed ostatn\u00e9), mo\u017enos\u0165 ladi\u0165 nastavenia na mieru ka\u017edej aplik\u00e1cii (napr. e-shop potrebuje viac procesov, mal\u00fd firemn\u00fd web menej), a preh\u013eadnos\u0165 &#8211; v logoch vid\u00edte ktor\u00fd pool hl\u00e1si chyby. V konfigura\u010dn\u00fdch s\u00faboroch potom budete ma\u0165 bloky ozna\u010den\u00e9<code> [nazov_poolu]<\/code> a pre ka\u017ed\u00fd vlastn\u00e9 pm, pm.max_children, at\u010f. Nginx\/Apache vhost konfigur\u00e1cia mus\u00ed by\u0165 upraven\u00e1, aby pr\u00edslu\u0161n\u00e9 URL smerovali na spr\u00e1vny socket\/port poolu. Toto je \u0161tandard pri webhostingu a ur\u010dite odpor\u00fa\u010dan\u00e9, ak spravujete heterog\u00e9nne aplik\u00e1cie (napr. WordPress + Laravel + Joomla na jednom stroji &#8211; ka\u017ed\u00e9 m\u00e1 in\u00fd profil z\u00e1\u0165a\u017ee, in\u00e9 <code>memory_limit<\/code> po\u017eiadavky, tak\u017ee dajte im oddelen\u00e9 pool-y).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Rozdelenie frontendu a backendu jednej aplik\u00e1cie&nbsp;<\/h3>\n\n\n\n<p>Aj v r\u00e1mci jednej aplik\u00e1cie (ak je robustn\u00e1) m\u00f4\u017eete v\u00fdkonnostne oddeli\u0165 \u010dasti. Typick\u00fd pr\u00edklad je CMS alebo e-shop s <em>frontendom<\/em> (verejn\u00e1 str\u00e1nka pre z\u00e1kazn\u00edkov) a <em>backendom<\/em> (administr\u00e1cia pre redakciu). Frontend m\u00e1 ve\u013ea po\u017eiadaviek od n\u00e1v\u0161tevn\u00edkov, mus\u00ed by\u0165 r\u00fdchly a \u0161k\u00e1lova\u0165 &#8211; tam nasad\u00edte pool s viacer\u00fdmi procesmi, mo\u017eno <em>static<\/em> alebo <em>dynamic<\/em> s vysok\u00fdmi limity. Backend pou\u017e\u00edvaj\u00fa len redaktori ob\u010das &#8211; tam sta\u010d\u00ed p\u00e1r procesov a pokojne <em>ondemand<\/em> (nech n\u00e1m napr\u00edklad zbyto\u010dne ne\u017eer\u00fa RAM, ke\u010f v noci nikto v redakcii nepracuje). Nastavenie je jednoduch\u00e9: vytvor\u00edte dva pooly (napr. <code>[frontend]<\/code> a <code>[backend]<\/code>) v konfigur\u00e1cii a v Nginx konfigur\u00e1cii pod\u013ea URL alebo dom\u00e9ny nasmerujete po\u017eiadavky bu\u010f na frontend alebo backend socket. Takto viete zabezpe\u010di\u0165, \u017ee ak n\u00e1hodou admin \u010das\u0165 spust\u00ed n\u00e1ro\u010dn\u00fa oper\u00e1ciu (napr. import produktov), nevy\u010derp\u00e1 v\u0161etky PHP procesy a frontend pre z\u00e1kazn\u00edkov bude st\u00e1le reagova\u0165 (preto\u017ee m\u00e1 vlastn\u00fd pool).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. Multi-tenancy (ve\u013ea poolov)&nbsp;<\/h3>\n\n\n\n<p>Ak hostujete stovky webov (napr. v r\u00e1mci jedn\u00e9ho VPS alebo kontajneru), po\u010det pool-ov sa rovn\u00e1 po\u010dtu webov. Tam nastupuje to, \u017ee <em>static<\/em> \u010di <em>dynamic<\/em> re\u017eim by pri 100 pooloch bol ne\u00fanosn\u00fd (100\u00d720 procesov = 2000 procesov v pam\u00e4ti st\u00e1le). Preto napr. cPanel v tak\u00fdch scen\u00e1roch pou\u017e\u00edva <em>ondemand<\/em> pre ka\u017ed\u00fd pool, aby pooly, ktor\u00e9 nemaj\u00fa traffic, nemali \u017eiadny proces a nebrali pam\u00e4\u0165. Administr\u00e1tor potom mus\u00ed voli\u0165 parametre tak, aby sum\u00e1rne v\u0161etky pooly neprekro\u010dili kapacity. \u010casto ide o kompromis &#8211; napr. nastavi\u0165 <code>max_children<\/code> ni\u017e\u0161ie, ne\u017e by si mohol dovoli\u0165 ka\u017ed\u00fd web samostatne, lebo pri 100 weboch by to u\u017e prekro\u010dilo RAM. Toto je komplexn\u00e1 problematika (ladenie multi-tenant servera) &#8211; odpor\u00fa\u010dame vtedy robustnej\u0161\u00ed monitoring, kontajneriz\u00e1ciu alebo rozdelenie z\u00e1\u0165a\u017ee na viac serverov, ak je mo\u017enos\u0165.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">N\u00e1stroje na testovanie a ladenie<\/h2>\n\n\n\n<p>Spome\u0148me nieko\u013eko u\u017eito\u010dn\u00fdch n\u00e1strojov a postupov, ktor\u00e9 administr\u00e1torovi pom\u00f4\u017eu pri laden\u00ed PHP-FPM:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Online kalkula\u010dky<\/strong>: U\u017e sme zmienili <strong>Spot13 PHP-FPM Calculator<\/strong>. Podobn\u00fd jednoduch\u00fd kalkul\u00e1tor pon\u00faka aj <a href=\"https:\/\/tideways.com\/tools\/fpm-configuration-calculator\">Tideways vo forme webovej aplik\u00e1cie<\/a>. Zada\u0165 mus\u00edte parametre RAM, CPU, odhad ve\u013ekosti procesu a zvol\u00edte typ pm (static\/dynamic) &#8211; n\u00e1stroj vyp\u013euje odpor\u00fa\u010dan\u00e9 nastavenia. Berte to ako v\u00fdchodiskov\u00fd bod, nie dogmu. Skuto\u010dn\u00e9 hodnoty si overte v prev\u00e1dzke.<\/li>\n\n\n\n<li><strong>Skripty tret\u00edch str\u00e1n<\/strong>: php-fpm_tuner sme u\u017e pop\u00edsali &#8211; sta\u010d\u00ed stiahnu\u0165 <code>php-fpm-tuner.php<\/code> a spusti\u0165 v pr\u00edkazovom riadku na serveri . Skript zist\u00ed vo\u013en\u00fa RAM, spo\u010d\u00edta priemern\u00fa ve\u013ekos\u0165 procesu (bu\u010f z be\u017eiacich, alebo pou\u017eije <code>memory_limit<\/code>) a navrhne <code>pm.max_children<\/code>, <code>start_servers<\/code>, at\u010f. V\u00fdhodou je, \u017ee zoh\u013eadn\u00ed aj po\u010det CPU jadier (aby nenavrhol nezmyselne ve\u013ea procesov). Nev\u00fdhodou m\u00f4\u017ee by\u0165, \u017ee ak skript spust\u00edte v neakt\u00edvnom \u010dase, nameria men\u0161ie procesy ne\u017e v \u0161pi\u010dke &#8211; \u010di\u017ee odhadne viac children, ne\u017e re\u00e1lne treba (\u010do by v \u0161pi\u010dke mohlo by\u0165 ve\u013ea). Preto ide\u00e1lne pustite tuner po\u010das typickej z\u00e1\u0165a\u017ee.&nbsp;<\/li>\n\n\n\n<li><strong>Monitoringov\u00e9 n\u00e1stroje<\/strong>: Na kontinu\u00e1lne sledovanie v\u00fdkonu odpor\u00fa\u010dame nasadi\u0165 nejak\u00fd monitorovac\u00ed syst\u00e9m. M\u00f4\u017ee to by\u0165 komplexn\u00e9 APM (Application Performance Monitoring) rie\u0161enie ako New Relic, Datadog at\u010f., ktor\u00e9 okrem metriky servera sleduje aj profil aplik\u00e1cie. Ak tak\u00fd n\u00e1stroj nem\u00e1te, aspo\u0148 si nastavte grafy cez Munin, Zabbix alebo in\u00fd syst\u00e9m, ktor\u00fd bude logova\u0165: vyu\u017eitie CPU, RAM, d\u013a\u017eku fronty PHP-FPM, po\u010det akt\u00edvnych vs. vo\u013en\u00fdch procesov, priemern\u00fd \u010das requestov a pod. Tieto \u00fadaje v\u00e1m pom\u00f4\u017eu dlhodobo doladi\u0165 konfigur\u00e1ciu &#8211; napr\u00edklad uvid\u00edte, \u017ee po nasaden\u00ed ur\u010ditej verzie webu st\u00fapla pam\u00e4\u0165ov\u00e1 n\u00e1ro\u010dnos\u0165, tak uprav\u00edte <code>max_children<\/code>. Alebo spozorujete trend, \u017ee n\u00e1v\u0161tevnos\u0165 rastie a po\u010das kampan\u00ed idete na hranu kapacity &#8211; viete vopred prida\u0165 v\u00fdkon (nav\u00fd\u0161i\u0165 parametre alebo prida\u0165 server).<\/li>\n\n\n\n<li><strong>Testovanie zmien postupne<\/strong>: Ak pl\u00e1nujete v\u00fdraznej\u0161ie z\u00e1sahy (napr. prechod z <em>dynamic<\/em> na <em>static<\/em> re\u017eim, alebo nav\u00fd\u0161enie procesov o +200%), otestujte to najprv bu\u010f na staging prostred\u00ed, alebo ve\u013emi opatrne na produkcii mimo \u0161pi\u010dky. Napr\u00edklad prepn\u00fa\u0165 z <em>dynamic<\/em> na <em>static<\/em>: M\u00f4\u017ee to prinies\u0165 zlep\u0161enie latenci\u00ed pri \u0161pi\u010dke, ale z\u00e1rove\u0148 to znamen\u00e1, \u017ee hne\u010f od \u0161tartu pobe\u017e\u00ed maximum procesov &#8211; teda ve\u013ek\u00e1 z\u00e1\u0165a\u017e na RAM a mo\u017eno aj CPU. Sk\u00faste najprv <em>static<\/em> s konzervat\u00edvnym po\u010dtom (napr. <em>static<\/em> + 50% aktu\u00e1lne be\u017en\u00fdch procesov). Sledujte, \u010do to sprav\u00ed s loadom. Admini \u010dasto prepn\u00fa na <em>static<\/em>, ke\u010f u\u017e presne vedia, ko\u013eko procesov ich server unesie bez probl\u00e9mov. <em>Static<\/em> re\u017eim nastavujte iba ak m\u00e1te dostato\u010dn\u00fa pam\u00e4\u0165ov\u00fa rezervu &#8211; inak riskujete, \u017ee v k\u013eudovom stave bude polovica RAM obsaden\u00e1 ne\u010dinn\u00fdmi procesmi, \u010do mo\u017eno ani nepotrebujete.<\/li>\n\n\n\n<li><strong>Trval\u00e9 ladenie<\/strong>: V\u00fdkonov\u00e9 ladenie nie je jednorazov\u00e1 akcia. V ide\u00e1lnom pr\u00edpade by ste sa mali k nastaveniam vr\u00e1ti\u0165 v\u017edy, ke\u010f sa zmenia podmienky &#8211; napr. upgrade PHP verzie (nov\u0161ie verzie m\u00f4\u017eu ma\u0165 in\u00fd memory footprint), zmena k\u00f3du aplik\u00e1cie (nasadenie novej funkcionality m\u00f4\u017ee v\u00fdrazne ovplyvni\u0165 z\u00e1\u0165a\u017e), zmena infra\u0161trukt\u00fary (napr. presun DB na in\u00fd server uvo\u013en\u00ed pam\u00e4\u0165 pre PHP, tak\u017ee m\u00f4\u017eete prida\u0165 procesy), alebo n\u00e1rast n\u00e1v\u0161tevnosti. Priebe\u017ene kontrolujte metriky a ak vid\u00edte, \u017ee napr. <code>max_children<\/code> nejak pravidelne dosahujete, upravte konfigur\u00e1ciu.<\/li>\n<\/ul>\n\n\n\n<p>E\u0161te jeden tip: ak bojujete s pam\u00e4\u0165ou a h\u013ead\u00e1te ka\u017ed\u00e9 vo\u013en\u00e9 MB, skontrolujte aj ostatn\u00e9 nastavenia PHP &#8211; napr. <code>disabled_functions<\/code>, nepotrebn\u00e9 moduly roz\u0161\u00edren\u00ed at\u010f. Niektor\u00ed admini dokonca rekompiluj\u00fa PHP s vyraden\u00edm nepotrebn\u00fdch modulov, aby zn\u00ed\u017eili ve\u013ekos\u0165 procesu. To u\u017e s\u00fa extr\u00e9my (a riskantn\u00e9 v produkcii), ale spomen\u00fa\u0165 to tu m\u00f4\u017eeme. Re\u00e1lnej\u0161ie je: ak napr\u00edklad nevyu\u017e\u00edvate Xdebug alebo in\u00e9 roz\u0161\u00edrenia na produkcii, uistite sa, \u017ee nie s\u00fa na\u010d\u00edtan\u00e9, lebo zaberaj\u00fa pam\u00e4\u0165. Taktie\u017e modul JIT (Just-In-Time kompil\u00e1tor, od PHP 8) &#8211; ten by mohol teoreticky zr\u00fdchli\u0165 niektor\u00e9 CPU-intenz\u00edvne \u00falohy, ale vo webov\u00fdch aplik\u00e1ci\u00e1ch zvy\u010dajne neprin\u00e1\u0161a v\u00fdznamn\u00e9 zlep\u0161enie, sk\u00f4r prid\u00e1va pam\u00e4\u0165ov\u00fa z\u00e1\u0165a\u017e. Odpor\u00fa\u010da sa preto JIT v produkcii bu\u010f \u00faplne vypn\u00fa\u0165, alebo aspo\u0148 nastavi\u0165 konzervat\u00edvne, pokia\u013e nem\u00e1te \u0161pecifick\u00fd d\u00f4vod ho pou\u017e\u00edva\u0165. V\u00fdkon webov sk\u00f4r vylep\u0161\u00ed spom\u00ednan\u00fd OPcache ne\u017e JIT.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Z\u00e1ver a \u010fal\u0161ie kroky<\/h2>\n\n\n\n<p>Ladenie PHP-FPM je do ur\u010ditej miery umeleck\u00e1 discipl\u00edna &#8211; vy\u017eaduje kombin\u00e1ciu znalosti syst\u00e9mu, experimentovania a priebe\u017en\u00e9ho sledovania v\u00fdsledkov. V tomto n\u00e1vode sme pre\u0161li hlavn\u00e9 oblasti konfigur\u00e1cie: v\u00fdber re\u017eimu spr\u00e1vy procesov (<em>static\/dynamic\/ondemand<\/em>) a jeho vplyv na latenciu vs. vyu\u017eitie zdrojov, nastavenie k\u013e\u00fa\u010dov\u00fdch parametrov ako <code>pm.max_children<\/code> a spol., a sp\u00f4sob, ako ich vypo\u010d\u00edta\u0165 pod\u013ea pam\u00e4te a za\u0165a\u017eenia servera. Zd\u00f4raznili sme, \u017ee v\u017edy treba bra\u0165 do \u00favahy \u0161pecifik\u00e1 v\u00e1\u0161ho prostredia &#8211; in\u00fd pr\u00edstup zvol\u00edte pre mal\u00fd web na 1 CPU s 2 GB RAM, in\u00fd pre ve\u013ek\u00fd server s 32 GB RAM a stovkami n\u00e1v\u0161tevn\u00edkov naraz. Rovnako sme upozornili na metodiku: robi\u0165 zmeny postupne, z\u00e1lohova\u0165, testova\u0165 pod z\u00e1\u0165a\u017eou a sledova\u0165 metriky.<\/p>\n\n\n\n<p><strong>Nezabudnite, \u017ee v\u0161etky tunings s\u00fa odpor\u00fa\u010dania, nie garantovan\u00e9 pravdy<\/strong>. Tuning \u010dasto prebieha iterat\u00edvne: uprav\u00edte konfigur\u00e1ciu, nasad\u00edte, pozorujete. Mo\u017eno odhal\u00edte nov\u00fd bottleneck inde (napr. datab\u00e1za nest\u00edha, ke\u010f PHP pust\u00edte naplno). Potom pr\u00edde na rad ladenie datab\u00e1zy, caching vrstvy at\u010f. <strong>V\u00fdkon webovej aplik\u00e1cie je len tak siln\u00fd, ako najslab\u0161\u00ed \u010dl\u00e1nok v re\u0165azi<\/strong>. PHP-FPM je d\u00f4le\u017eit\u00fd \u010dl\u00e1nok, ale ak v k\u00f3de be\u017e\u00ed neoptim\u00e1lna \u00faloha, mus\u00edte rie\u0161i\u0165 aj ju. Preto na \u010fal\u0161ie kroky odpor\u00fa\u010dame:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Analyzova\u0165 aplik\u00e1ciu<\/strong> &#8211; vyu\u017eite slowlog, profily (Xdebug, Tideways, New Relic) na identifikovanie pomal\u00fdch \u010dast\u00ed k\u00f3du. Mo\u017eno zist\u00edte, \u017ee sta\u010d\u00ed prida\u0165 index v datab\u00e1ze alebo zapn\u00fa\u0165 cache na ur\u010dit\u00e9 d\u00e1ta a server zrazu zvl\u00e1dne dvojn\u00e1sobok.<\/li>\n\n\n\n<li><strong>Sledova\u0165 nov\u00e9 verzie PHP<\/strong>: PHP 8.1-8.4 priniesli r\u00f4zne optimaliz\u00e1cie. Ka\u017ed\u00e1 verzia ob\u010das men\u00ed spr\u00e1vanie garbage collection, JIT, a drobnosti, ktor\u00e9 m\u00f4\u017eu ovplyvni\u0165 memory footprint. Pri prechode napr. z PHP 8.1 na 8.2 si overte, \u010di nepotrebujete mierne doladi\u0165 parametre (spravidla rozdiely nie s\u00fa ve\u013ek\u00e9, ale napr. nov\u00fd typ alebo in\u00e9 intern\u00e9 vylep\u0161enia m\u00f4\u017eu ovplyvni\u0165 vyu\u017eitie pam\u00e4te o p\u00e1r percent). Zdroje k v\u00fdkonov\u00fdm novink\u00e1m zvykn\u00fa by\u0165 v <em>Migration Guide<\/em> danej verzie.<\/li>\n\n\n\n<li><strong>Bezpe\u010dnos\u0165 a stabilita<\/strong>: Pri extr\u00e9mnom laden\u00ed na v\u00fdkon nezanedbajte stabilitu. Napr\u00edklad nastavi\u0165<code> pm.max_requests = 0<\/code> a pm.static s ve\u013ek\u00fdm po\u010dtom procesov d\u00e1 maxim\u00e1lny v\u00fdkon, ale ak sa predsa vyskytne memory leak, postupne v\u00e1m to m\u00f4\u017ee zjes\u0165 cel\u00fa RAM. Alebo vypnutie \u010dasov\u00fdch limitov m\u00f4\u017ee sp\u00f4sobi\u0165, \u017ee vis\u00ed proces cel\u00e9 hodiny na zlej oper\u00e1cii. N\u00e1jdite balans medzi v\u00fdkonom a robustnos\u0165ou. Rad\u0161ej o p\u00e1r percent ni\u017e\u0161\u00ed v\u00fdkon, ale server, ktor\u00fd sa nezr\u00fati pri prvej anom\u00e1lii.<\/li>\n<\/ul>\n\n\n\n<p>Na z\u00e1ver treba poveda\u0165: <strong>ak va\u0161a konfigur\u00e1cia funguje stabilne a v\u00fdkon je dostato\u010dn\u00fd, nie je nutn\u00e9 ju silou-mocou <em>\u201e<\/em>tuni\u0165\u201d<\/strong>. Nemeni\u0165 to, \u010do funguje &#8211; aj to je z\u00e1sada. V\u00fdkonov\u00e9 ladenie m\u00e1 zmysel, ak nar\u00e1\u017eate na limity alebo chcete pred\u00eds\u0165 bud\u00facim probl\u00e9mom pri raste z\u00e1\u0165a\u017ee. Dobre nastaven\u00e9 PHP-FPM dok\u00e1\u017ee obsl\u00fa\u017ei\u0165 tis\u00edce paraleln\u00fdch u\u017e\u00edvate\u013eov na vhodnom hardv\u00e9ri. Ak v\u0161ak potreby v\u00e1\u0161ho webu prerast\u00fa kapacity jedn\u00e9ho servera, mo\u017eno nastal \u010das zv\u00e1\u017ei\u0165 \u0161k\u00e1lovanie horizont\u00e1lne (viac serverov s load balancerom) alebo nasadenie kontajneriz\u00e1cie (Docker\/Kubernetes), kde m\u00f4\u017eete flexibilne prid\u00e1va\u0165 PHP-FPM in\u0161tancie pod\u013ea z\u00e1\u0165a\u017ee.<\/p>\n\n\n\n<p><strong>D\u00f4le\u017eit\u00e9 je priebe\u017ene monitorova\u0165 a prisp\u00f4sobova\u0165 nastavenia<\/strong> &#8211; \u010do plat\u00ed dnes, nemus\u00ed sta\u010di\u0165 zajtra pri inom type prev\u00e1dzky. Ver\u00edme, \u017ee tento n\u00e1vod v\u00e1m poskytol potrebn\u00e9 znalosti a best practices, aby ste mohli nastavi\u0165 PHP-FPM optim\u00e1lne pre PHP 8.1 a\u017e 8.4 a \u010falej.&nbsp;<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Sp\u00fdtajte sa n\u00e1s, radi porad\u00edme<\/h4>\n\n\n\n<p>Ak si s niektor\u00fdmi nastaveniami neviete da\u0165 rady alebo potrebujete konzultova\u0165 optim\u00e1lnu konfigur\u00e1ciu pre v\u00e1\u0161 konkr\u00e9tny projekt, nev\u00e1hajte sa obr\u00e1ti\u0165 na na\u0161u podporu. Sme pripraven\u00ed pom\u00f4c\u0165 so spr\u00e1vnym nastaven\u00edm PHP-FPM, ako aj \u010fal\u0161\u00edch slu\u017eieb na va\u0161om serveri, aby v\u00e1\u0161 web be\u017eal \u010do najr\u00fdchlej\u0161ie a najspo\u013eahlivej\u0161ie. V\u00fdkonov\u00e9 ladenie m\u00f4\u017ee by\u0165 n\u00e1ro\u010dn\u00e9, ale s odbornou pomocou to ur\u010dite zvl\u00e1dnete.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri. PHP-FPM predstavuje preferovan\u00fd sp\u00f4sob prev\u00e1dzky PHP na modern\u00fdch serveroch &#8211; je flexibilnej\u0161\u00ed na konfigur\u00e1ciu a efekt\u00edvnej\u0161\u00ed pri obsluhe vysok\u00e9ho po\u010dtu po\u017eiadaviek ne\u017e tradi\u010dn\u00fd modul mod_php v Apache.&nbsp; Z\u00e1rove\u0148 v\u0161ak predvolen\u00e9 nastavenia konfigur\u00e1cie PHP-FPM&#8230;<\/p>\n","protected":false},"author":57,"template":"","format":"standard","meta":{"footnotes":""},"ht-kb-category":[228,52,53,33],"ht-kb-tag":[330,207,381,192,189],"class_list":["post-33827","ht_kb","type-ht_kb","status-publish","format-standard","hentry","ht_kb_category-vdc","ht_kb_category-vps","ht_kb_category-dedikovane-servery","ht_kb_category-servery","ht_kb_tag-linux","ht_kb_tag-php","ht_kb_tag-server","ht_kb_tag-vdc","ht_kb_tag-vps"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov - Websupport centrum podpory<\/title>\n<meta name=\"description\" content=\"Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/\" \/>\n<meta property=\"og:locale\" content=\"sk_SK\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov - Websupport centrum podpory\" \/>\n<meta property=\"og:description\" content=\"Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/\" \/>\n<meta property=\"og:site_name\" content=\"Websupport centrum podpory\" \/>\n<meta property=\"article:modified_time\" content=\"2025-10-17T07:23:54+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.websupport.sk\/podpora\/app\/uploads\/sites\/2\/2025\/10\/LADENIE-VYKONU-PHP-S-PHP-FPM_1200x1200.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"1200\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Predpokladan\u00fd \u010das \u010d\u00edtania\" \/>\n\t<meta name=\"twitter:data1\" content=\"33 min\u00fat\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/\",\"url\":\"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/\",\"name\":\"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov - Websupport centrum podpory\",\"isPartOf\":{\"@id\":\"https:\/\/www.websupport.sk\/podpora\/#website\"},\"datePublished\":\"2025-10-17T07:20:08+00:00\",\"dateModified\":\"2025-10-17T07:23:54+00:00\",\"description\":\"Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/#breadcrumb\"},\"inLanguage\":\"sk-SK\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.websupport.sk\/podpora\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.websupport.sk\/podpora\/#website\",\"url\":\"https:\/\/www.websupport.sk\/podpora\/\",\"name\":\"Websupport centrum podpory\",\"description\":\"Radi v\u00e1m pom\u00f4\u017eeme s va\u0161im probl\u00e9mom\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.websupport.sk\/podpora\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"sk-SK\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov - Websupport centrum podpory","description":"Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/","og_locale":"sk_SK","og_type":"article","og_title":"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov - Websupport centrum podpory","og_description":"Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri.","og_url":"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/","og_site_name":"Websupport centrum podpory","article_modified_time":"2025-10-17T07:23:54+00:00","og_image":[{"width":1200,"height":1200,"url":"https:\/\/www.websupport.sk\/podpora\/app\/uploads\/sites\/2\/2025\/10\/LADENIE-VYKONU-PHP-S-PHP-FPM_1200x1200.png","type":"image\/png"}],"twitter_card":"summary_large_image","twitter_misc":{"Predpokladan\u00fd \u010das \u010d\u00edtania":"33 min\u00fat"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/","url":"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/","name":"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov - Websupport centrum podpory","isPartOf":{"@id":"https:\/\/www.websupport.sk\/podpora\/#website"},"datePublished":"2025-10-17T07:20:08+00:00","dateModified":"2025-10-17T07:23:54+00:00","description":"Spr\u00e1vne vyladenie v\u00fdkonu PHP-FPM (FastCGI Process Manager) je k\u013e\u00fa\u010dov\u00e9 pre r\u00fdchlos\u0165 a stabilitu webov\u00fdch aplik\u00e1ci\u00ed na serveri.","breadcrumb":{"@id":"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/#breadcrumb"},"inLanguage":"sk-SK","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.websupport.sk\/podpora\/kb\/ladenie-vykonu-php-s-php-fpm-pre-systemovych-administratorov\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.websupport.sk\/podpora\/"},{"@type":"ListItem","position":2,"name":"Ladenie v\u00fdkonu PHP s PHP-FPM pre syst\u00e9mov\u00fdch administr\u00e1torov"}]},{"@type":"WebSite","@id":"https:\/\/www.websupport.sk\/podpora\/#website","url":"https:\/\/www.websupport.sk\/podpora\/","name":"Websupport centrum podpory","description":"Radi v\u00e1m pom\u00f4\u017eeme s va\u0161im probl\u00e9mom","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.websupport.sk\/podpora\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"sk-SK"}]}},"_links":{"self":[{"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/ht-kb\/33827","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/ht-kb"}],"about":[{"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/types\/ht_kb"}],"author":[{"embeddable":true,"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/users\/57"}],"version-history":[{"count":4,"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/ht-kb\/33827\/revisions"}],"predecessor-version":[{"id":34091,"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/ht-kb\/33827\/revisions\/34091"}],"wp:attachment":[{"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/media?parent=33827"}],"wp:term":[{"taxonomy":"ht_kb_category","embeddable":true,"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/ht-kb-category?post=33827"},{"taxonomy":"ht_kb_tag","embeddable":true,"href":"https:\/\/www.websupport.sk\/podpora\/wp-json\/wp\/v2\/ht-kb-tag?post=33827"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}