Optimalizácia PHP-FPM pre vysoký výkon

PHP je všade a je to pravdepodobne jazyk najrozšírenejší na internete.


Nie je však presne známy svojimi vysokovýkonnými schopnosťami, najmä pokiaľ ide o vysoko súbežné systémy. A to je dôvod, prečo v takýchto prípadoch špeciálneho použitia preberajú jazyky ako Node (áno, viem, že to nie je jazyk), Go a Elixir..

To znamená, že existuje veľa, ktoré môžete urobiť, aby ste zlepšili výkon PHP na svojom serveri. Tento článok sa zameriava na stránku php-fpm, čo je prirodzený spôsob konfigurácie na vašom serveri, ak používate Nginx..

Ak viete, čo je php-fpm, prejdite na časť o optimalizácii.

Čo je php-fpm?

Nie veľa vývojárov sa zaujíma o DevOps na strane vecí a dokonca aj medzi tými, ktorí to robia, veľmi málo vie, čo sa deje pod kapotou. Je zaujímavé, že keď prehliadač odošle požiadavku serveru so spusteným PHP, nie je to PHP, ktoré tvorí bod prvého kontaktu; namiesto toho je to server HTTP, z ktorých najvýznamnejšie sú Apache a Nginx. Tieto „webové servery“ sa potom musia rozhodnúť, ako sa pripojiť k PHP a odovzdať do nich typ žiadosti, údaje a hlavičky..

Cyklus požiadavka-odpoveď v prípade PHP (Image Credit: ProinerTech)

V moderných PHP aplikáciách je časťou „find file“ vyššie index.php, ktorú je server nakonfigurovaný na delegovanie všetkých požiadaviek na.

Teraz, ako presne sa webový server pripája k PHP, sa vyvinul, a tento článok by explodoval do hĺbky, ak by sme sa dostali do všetkej nemravnosti. Zhruba povedané, v čase, keď Apache dominoval ako zvolený webový server, bol PHP súčasťou servera.

Takže vždy, keď bola prijatá požiadavka, server by začal nový proces, ktorý bude automaticky obsahovať PHP a bude vykonaný. Táto metóda sa volala mod_php, skratka pre „php ako modul“. Tento prístup mal svoje obmedzenia, ktoré Nginx prekonal s php-fpm.

V php-fpm je zodpovednosť za správu PHP procesy spojené s programom PHP v rámci servera. Inými slovami, webový server (v našom prípade Nginx) sa nestará o to, kde je PHP a ako sa načíta, pokiaľ vie, ako z neho odosielať a prijímať údaje. Pokiaľ chcete, môžete v tomto prípade uvažovať o PHP ako o inom serveri ako takom, ktorý riadi niektoré podriadené procesy PHP pre prichádzajúce požiadavky (takže máme požiadavku dosiahnuť server, ktorý bol prijatý serverom a odovzdaný na server – dosť šialené! :-P).

Ak ste už vykonali nejaké nastavenia Nginxu alebo ste do nich len prišli, narazíte na niečo také:

umiestnenie ~ \ .php $ {
try_files $ uri = 404;
fastcgi_split_path_info ^ (. + \. php) (/.+) $;
fastcgi_pass unix: /run/php/php7.2-fpm.sock;
fastcgi_index index.php;
zahŕňajú fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;
}

Riadok, ktorý nás zaujíma, je tento: fastcgi_pass unix: /run/php/php7.2-fpm.sock ;, ktorý hovorí Nginxu, aby komunikoval s procesom PHP prostredníctvom soketu s názvom php7.2-fpm.sock. Nginx pre každú prichádzajúcu požiadavku zapíše údaje prostredníctvom tohto súboru a po prijatí výstupu ich odošle späť do prehliadača.

Ešte raz musím zdôrazniť, že nejde o najkompletnejší alebo najpresnejší obraz o tom, čo sa deje, ale je to úplne presné pre väčšinu úloh DevOps..

Okrem toho zhrnieme, čo sme sa doteraz naučili:

  • PHP priamo neprijíma požiadavky odoslané prehliadačmi. Webové servery ako Nginx ich najprv zachytia.
  • Webový server vie, ako sa pripojiť k procesu PHP a odovzdáva všetky údaje o požiadavkách (doslova vkladá všetko) do PHP.
  • Keď PHP dokončí svoju časť, pošle odpoveď späť na webový server, ktorý ju pošle späť klientovi (alebo prehliadaču, vo väčšine prípadov).

Alebo graficky:

Ako PHP a Nginx spolupracujú (kredit obrázku: DataDog)

Zatiaľ skvelé, ale teraz prichádza otázka miliónov dolárov: čo presne je PHP-FPM?

Časť „FPM“ v PHP znamená „Fast Process Manager“, čo je len vymyslený spôsob, ako povedať, že PHP bežiace na serveri nie je jediný proces, ale skôr niektoré procesy PHP, ktoré vznikajú, kontrolujú a zabíjajú. od tohto správcu procesov FPM. Webový server odovzdáva žiadosti týmto správcovi procesov.

PHP-FPM je samo o sebe celá králičia diera, takže neváhajte a preskúmajte, či si želáte, ale pre naše účely to bude také vysvetlenie. ��

Prečo optimalizovať php-fpm?

Tak prečo sa obávať všetkého tohto tanca, keď veci fungujú dobre? Prečo nielen nechať veci také, aké sú.

Je iróniou, že to je presne rada, ktorú poskytujem pre väčšinu prípadov použitia. Ak vaše nastavenie funguje dobre a nemá mimoriadne prípady použitia, použite predvolené hodnoty. Ak však chcete zväčšiť veľkosť jedného počítača, je nevyhnutné vytlačiť maximum z jedného, ​​pretože môže znížiť účty za server na polovicu (alebo dokonca viac!).

Ďalšou vecou, ​​ktorú si treba uvedomiť, je, že Nginx bol postavený na zvládnutie obrovského pracovného zaťaženia. Je schopný zvládnuť tisíce spojení súčasne, ale ak to isté neplatí pre vaše nastavenie PHP, budete strácať zdroje, pretože Nginx bude musieť počkať, kým PHP skončí súčasným procesom a akceptovať ďalej, presvedčivo negatívne akékoľvek výhody, ktoré spoločnosť Nginx vytvorila!

Takže, keď to znemožníme, pozrime sa, čo presne by sme zmenili pri pokuse o optimalizáciu php-fpm.

Ako optimalizovať PHP-FPM?

Umiestnenie konfiguračného súboru pre php-fpm sa môže na serveri líšiť, takže pre jeho nájdenie budete musieť urobiť nejaký prieskum. Príkaz find môžete použiť v systéme UNIX. Na mojom Ubuntu je cesta /etc/php/7.2/fpm/php-fpm.conf. 7.2 je, samozrejme, verzia PHP, ktorú používam.

Ako vyzerá prvých pár riadkov tohto súboru:

;;;;;;;;;;;;;;;;;;;;;
; Konfigurácia FPM;
;;;;;;;;;;;;;;;;;;;;;

; Všetky relatívne cesty v tomto konfiguračnom súbore sú relatívne k inštalácii PHP
; predpona (/ usr). Táto predpona sa dá dynamicky zmeniť pomocou
; Argument ‘-p’ z príkazového riadku.

;;;;;;;;;;;;;;;;;;
; Globálne možnosti;
;;;;;;;;;;;;;;;;;;

[Global]
; Súbor Pid
; Poznámka: predvolená predpona je / var
; Predvolená hodnota: žiadna
pid = /run/php/php7.2-fpm.pid

; Súbor denníka chýb
; Ak je nastavená na "syslog", protokol sa namiesto toho zapisuje do syslogd
; do lokálneho súboru.
; Poznámka: predvolená predpona je / var
; Predvolená hodnota: log / php-fpm.log
error_log = /var/log/php7.2-fpm.log

Okamžite by malo byť zrejmé niekoľko vecí: riadok pid = /run/php/php7.2-fpm.pid nám hovorí, ktorý súbor obsahuje ID procesu php-fpm procesu.

Tiež vidíme, že /var/log/php7.2-fpm.log je miesto, kde php-fpm bude ukladať svoje denníky.

Do tohto súboru pridajte ďalšie tri podobné premenné:

Emergency_restart_threshold 10
Emergency_restart_interval 1m
process_control_timeout 10s

Prvé dve nastavenia sú opatrné a hovoria procesu php-fpm, že ak zlyhá desať podriadených procesov do jednej minúty, mal by sa samotný hlavný proces php-fpm reštartovať..

To nemusí znieť robustne, ale PHP je proces s krátkou životnosťou, ktorý vytečuje pamäť, takže reštartovanie hlavného procesu v prípade vysokého zlyhania môže vyriešiť veľa problémov.

Tretia možnosť, process_control_timeout, hovorí dcérskym procesom, aby počkali toľko času, kým vykonajú signál prijatý z rodičovského procesu. Je to užitočné v prípadoch, keď sú podriadené procesy uprostred niečoho, keď napríklad materské procesy vysielajú signál KILL. Po desiatich sekundách budú mať väčšiu šancu dokončiť svoje úlohy a elegantne vystúpiť.

Prekvapivo to nie je mäso konfigurácie php-fpm! Je to preto, že na vykonávanie webových požiadaviek php-fpm vytvára novú skupinu procesov, ktorá bude mať samostatnú konfiguráciu. V mojom prípade sa názov fondu ukázal ako www a súbor, ktorý som chcel upraviť, bol /etc/php/7.2/fpm/pool.d/www.conf..

Pozrime sa, ako tento súbor začína:

; Založte nový fond s názvom „www“.
; premenná $ pool môže byť použitá v akejkoľvek smernici a bude nahradená
; názov skupiny (tu „www“)
[Www]

; Podľa predpony fondu
; Uplatňuje sa iba na tieto smernice:
; – ‘access.log’
; – ‘slowlog’
; – ‘počúvať’ (unixsocket)
; – ‘chroot’
; – „chdir“
; – ‘php_values’
; – ‘php_admin_values’
; Ak nie je nastavené, použije sa namiesto toho globálna predpona (alebo / usr).
; Poznámka: Táto smernica sa môže vzťahovať aj na globálnu predponu.
; Predvolená hodnota: žiadna
; prefix = / cesta / k / pooly / $ oblasť

; Unixový užívateľ / skupina procesov
; Poznámka: Používateľ je povinný. Ak skupina nie je nastavená, predvolená skupina používateľov
; bude použitý.
user = www-data
group = www-data

Rýchly pohľad na koniec úryvku vyššie vyrieši hádanku, prečo serverový proces beží ako www-dáta. Ak pri nastavovaní svojej webovej stránky narazíte na problémy s oprávnením na prístup k súborom, pravdepodobne ste zmenili vlastníka alebo skupinu adresára na údaje www, čo umožňuje procesu PHP zapisovať do protokolových súborov a odovzdávať dokumenty atď..

Nakoniec sa dostávame k zdroju záležitosti, nastavenia procesného manažéra (pm). Štandardne uvidíte predvolené hodnoty ako niečo také:

pm = dynamický
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

Čo teda „dynamický”Tu znamená? Myslím si, že oficiálne dokumenty to najlepšie vysvetľujú (myslím, že by to už malo byť súčasťou súboru, ktorý upravujete, ale reprodukoval som ho tu len pre prípad, že to tak nie je):

; Vyberte, ako bude procesný manažér riadiť počet podriadených procesov.
; Možné hodnoty:
; statický – pevný počet (pm.max_children) detských procesov;
; dynamický – počet podriadených procesov je nastavený dynamicky na základe
; podľa nasledujúcich smerníc. S týmto procesným riadením to bude
; vždy aspoň 1 dieťa.
; pm.max_children – maximálny počet detí, ktoré môžu
; byť nažive súčasne.
; pm.start_servers – počet detí vytvorených pri štarte.
; pm.min_spare_servers – minimálny počet detí v „nečinnosti“
; stav (čaká sa na spracovanie). Ak je to číslo
; „nečinných“ procesov je menej ako toto
; číslo potom budú vytvorené niektoré deti.
; pm.max_spare_servers – maximálny počet detí v „nečinnosti“
; stav (čaká sa na spracovanie). Ak je to číslo
; „nečinných“ procesov je vyššia ako táto
; číslo potom budú niektoré deti zabité.
; ondemand – pri štarte nie sú vytvorené žiadne deti. Keď budú deti, budú rozvetvené
; nové žiadosti sa spoja. Používajú sa tieto parametre:
; pm.max_children – maximálny počet detí, ktoré
; môže byť nažive súčasne.
; pm.process_idle_timeout – počet sekúnd, po ktorých
; nečinný proces bude zabitý.
; Poznámka: Táto hodnota je povinná.

Vidíme teda, že existujú tri možné hodnoty:

  • statický: Bez ohľadu na to sa bude udržiavať pevný počet procesov PHP.
  • dynamický: Dostaneme špecifikovať minimálny a maximálny počet procesov, ktoré php-fpm udržiava nažive v danom okamihu..
  • na požiadanie: Procesy sa vytvárajú a ničia dobre, na požiadanie.

Ako teda záleží na týchto nastaveniach?

Jednoducho povedané, ak máte webovú stránku s nízkou návštevnosťou, „dynamické“ nastavenie je väčšinou stratou zdrojov. Za predpokladu, že máte pm.min_spare_servers nastavené na 3, tri procesy PHP sa vytvoria a budú udržiavať, aj keď na webe nebude žiadny prenos. V takýchto prípadoch je lepšia voľba „ondemand“, ktorá umožňuje systému rozhodnúť, kedy začať nové procesy.

Na druhej strane, webové stránky, ktoré spracúvajú veľké množstvo prenosov alebo musia rýchlo reagovať, budú v tomto nastavení potrestané. Vytvorenie nového procesu PHP, jeho začlenenie do skupiny a jeho monitorovanie je navyše režijné náklady, ktorým je najlepšie sa vyhnúť.

Použitie pm = static opravuje počet podriadených procesov a umožňuje maximálny systémový prostriedok, ktorý sa má použiť pri uspokojovaní požiadaviek, a nie pri riadení PHP. Ak pôjdete touto cestou, majte na pamäti, že má svoje pokyny a nástrahy. Je to dosť hustý, ale veľmi užitočný článok tu.

Záverečné slová

Keďže články o výkone webu môžu vyvolať vojny alebo slúžiť k zmäteniu ľudí, mám pocit, že pred uzavretím tohto článku je niekoľko slov v poriadku. Ladenie výkonu je toľko o dohadoch a temnom umení, ako o systémových znalostiach.

Aj keď poznáte všetky nastavenia php-fpm srdcom, úspech nie je zaručený. Ak ste nemali potuchy o existencii php-fpm, nemusíte strácať čas staraním. Len robte to, čo už robíte a pokračujte.

Zároveň sa vyvarujte konca, aby ste boli výkonným feťákom. Áno, môžete dosiahnuť ešte lepší výkon tým, že zkompilujete PHP od nuly a odstránite všetky moduly, ktoré nebudete používať, ale tento prístup nie je v produkčných prostrediach dostatočne zdravý. Celá myšlienka optimalizácie je preskúmať, či sa vaše potreby líšia od predvolených hodnôt (ktoré zriedka robia!) A podľa potreby vykonať drobné zmeny..

Ak nie ste pripravení tráviť čas optimalizáciou serverov PHP, môžete zvážiť využitie spoľahlivej platformy ako KINŠTA ktorí sa starajú o optimalizáciu výkonu a bezpečnosť.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map