In unbewurke ferzje fan dit artikel waard oarspronklik publisearre op en publisearre hjir mei har tastimming .
Ik sil jo yn in notedop fertelle hoe't jo PHP-FPM it bêste kinne konfigurearje om trochput te fergrutsjen, latency te ferminderjen en CPU en ûnthâld mear konsekwint te brûken. Standert is de PM (prosesbehearder) line yn PHP-FPM dynamic, En as jo net genôch ûnthâld hawwe, dan is it better om te ynstallearjen op oanfraach. Litte wy 2 kontrôleopsjes fergelykje basearre op 'e php.net-dokumintaasje en sjen hoe't myn favoryt fan har ferskilt statyske pm foar hege folume ferkear:
pm = dynamysk - it oantal bernprosessen is dynamysk konfigureare op basis fan de folgjende rjochtlinen: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = op oanfraach - prosessen wurde makke op fraach (yn tsjinstelling ta dynamyske skepping, doe't pm.start_servers wurde lansearre as de tsjinst begjint).
pm = statysk - it oantal bernprosessen is fêst en wurdt oanjûn troch de parameter pm.max_children.
Foar details, sjoch .
Oerienkomsten tusken de PHP-FPM proses manager en de CPU frekwinsje controller
Dit kin offtopic lykje, mar ik sil dit keppelje oan it ûnderwerp fan PHP-FPM-konfiguraasje. Wa hat net teminsten ien kear in prosessor fertraging meimakke - op in laptop, firtuele masine of tawijd server? Unthâld CPU frekwinsje skaalfergrutting? Dizze opsjes binne beskikber foar nix en Windows kinne systeemprestaasjes en responsiviteit ferbetterje troch de prosessorgasynstelling te feroarjen fan op oanfraach op optreden*. Litte wy dizze kear de beskriuwingen fergelykje en nei de oerienkomsten sjen:
gûverneur = op oanfraach - dynamyske skaalfergrutting fan prosessorfrekwinsje ôfhinklik fan 'e hjoeddeistige lading. Springt rap nei maksimale frekwinsje en ferminderet it dan as perioaden fan ynaktiviteit tanimme.
gûverneur=konservatyf= dynamyske frekwinsje skaalfergrutting ôfhinklik fan de hjoeddeiske lading. Fergruttet en ferminderet frekwinsje soepeler dan op oanfraach.
Gûverneur = prestaasje - frekwinsje is altyd maksimum.
Foar details, sjoch .
Sjoch de oerienkomsten? Ik woe dizze fergeliking sjen litte om jo te oertsjûgjen dat it it bêste is om te brûken pm statysk foar PHP-FPM.
Foar de prosessor regulator parameter optreden helpt om de prestaasjes feilich te ferheegjen, om't it hast folslein ôfhinklik is fan 'e CPU-limyt fan 'e server. Njonken dit binne der fansels ek faktoaren lykas temperatuer, batterijlading (yn in laptop) en oare by-effekten fan it konstant draaien fan de prosessor op 100%. De prestaasjesynstelling soarget foar de rapste prosessorprestaasjes. Lês bygelyks oer , wêrmei't it RPi-paniel de regulator brûke sil optreden, wêr't de prestaasjesferbettering mear merkber wêze sil troch de lege CPU-kloksnelheid.
It brûken fan pm statysk om maksimale serverprestaasjes te berikken
PHP-FPM opsje pm statysk hinget foar in grut part ôf fan it frije ûnthâld op de tsjinner. As it ûnthâld leech is, is it better om te kiezen op oanfraach of dynamic. Oan 'e oare kant, as jo ûnthâld hawwe, kinne jo de PHP-prosesbehearder overhead foarkomme troch pm yn te stellen statyske oant de maksimale serverkapasiteit. Mei oare wurden, as alles goed berekkene is, moatte jo fêststelle pm.statysk oant it maksimale folume fan PHP-FPM-prosessen dat kin wurde útfierd, sûnder problemen te meitsjen mei leech ûnthâld of cache. Mar net sa heech dat it de processors oerweldiget en in boskje PHP-FPM-operaasjes sammelet dy't wachtsje om te wurde útfierd.
Yn it skermôfbylding hjirboppe hat de tsjinner pm = statysk en pm.max_children = 100, en dit nimt up likernôch 10 GB út de beskikbere 32. Jou omtinken oan de markearre kolommen, alles is dúdlik hjir. Yn dit skermôfbylding wiene d'r sawat 200 aktive brûkers (mear as 60 sekonden) yn Google Analytics. Op dit nivo binne sawat 70% fan PHP-FPM-berneprosessen noch idle. Dit betsjut dat PHP-FPM altyd ynsteld is op it maksimale oantal serverboarnen, nettsjinsteande it hjoeddeistige ferkear. In idle proses wachtet op ferkearspieken en reagearret direkt. Jo hoege net te wachtsjen oant pm sil berneprosessen oanmeitsje en se dan beëinigje as de perioade ferrint pm.process_idle_timeout. Ik set de wearde op hiel heech pm.max_requestsom't dit in wurkjende tsjinner is mei gjin ûnthâldlekken yn PHP. Jo kinne ynstallearje pm.max_requests = 0 mei statyske as jo folslein fertrouwen binne yn besteande en takomstige PHP-skripts. Mar it is better om de skripts oer de tiid wer út te fieren. Stel in grut oantal oanfragen yn, om't wy ûnnedige pm-kosten wolle foarkomme. Bygelyks, op syn minst pm.max_requests = 1000 - ôfhinklik fan kwantiteit pm.max_children en it oantal oanfragen per sekonde.
It skermôfbylding lit it kommando sjen , filtere troch u (brûker) en PHP-FPM brûkersnamme. Allinnich de earste 50 of sa prosessen wurde werjûn (ik telde net krekt), mar yn wêzen toant boppe de top statistiken dy't passe yn de terminal finster. Yn dit gefal sortearre troch % CPU (% CPU). Om alle 100 PHP-FPM-prosessen te sjen, útfiere it kommando:
top -bn1 | grep php-fpmWannear te brûken pm ondemand en dynamysk
As jo brûke pm dynamic, flaters lykas dit foarkomme:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total childrenBesykje de parameter te feroarjen, de flater sil net fuortgean, lykas . Yn dit gefal wie de pm.min-wearde te lyts, en om't webferkear safolle fariearret en hege toppen en djippe dellingen hat, is it lestich om pm adekwaat oan te passen dynamic. Gewoanlik wurdt pm brûkt op oanfraach, . Mar dit is noch slimmer, omdat op oanfraach terminates idle prosessen oan nul as der in bytsje of gjin ferkear, en jo sille noch einigje mei de overhead fan feroarjende ferkear. Utsein as jo fansels in enoarme wachttiid ynstelle. En dan is it better om te brûken pm.statysk + heech oantal pm.max_requests.
PM dynamic en benammen op oanfraach kin fan pas komme as jo meardere PHP-FPM-pools hawwe. Jo hostje bygelyks meardere cPanel-akkounts as meardere websiden yn ferskate pools. Ik haw in server mei bygelyks 100+ cpanel-akkounts en sawat 200 domeinen, en pm.static of sels dynamysk soe my net rêde. Alles wat jo hjir nedich binne op oanfraach, ommers, mear as twa tredde fan websiden krije in bytsje of gjin ferkear, en mei op oanfraach alle bern prosessen sille falle ôf, dat sil besparje ús in soad ûnthâld! Gelokkich hawwe de cPanel-ûntwikkelders dit opmurken en de wearde ynsteld op standert op oanfraach. Earder, doe't de standert wie dynamic, PHP-FPM wie hielendal net geskikt foar drokke dielde tsjinners. In protte hawwe brûkt suPHP,om't pm dynamic konsumearre ûnthâld sels mei idle pools en cPanel PHP-FPM akkounts. Meast wierskynlik, as it ferkear goed is, sille jo net wurde host op in server mei in grut oantal PHP-FPM-pools (dielde hosting).
konklúzje
As jo PHP-FPM brûke en jo ferkear is swier, prosesbehearders op oanfraach и dynamic foar PHP-FPM sil wurde beheind trochstreaming fanwege harren ynherinte overhead. Begryp jo systeem en konfigurearje PHP-FPM-prosessen neffens de maksimale serverkapasiteit. Earste set pm.max_children ôfhinklik fan maksimale pm-gebrûk dynamic of op oanfraach, en dan fergrutsje dizze wearde nei in nivo dêr't it ûnthâld en prosessor sil wurkje sûnder in oerladen. Jo sille fernimme dat mei pm statysk, om't jo alles yn it ûnthâld hawwe, sille ferkearspikes yn 'e rin fan' e tiid minder CPU-spikes feroarsaakje, en tsjinner- en CPU-ladingsgemiddelden sille nivellerje. De gemiddelde PHP-FPM-prosesgrutte hinget ôf fan 'e webserver en fereasket hânmjittige konfiguraasje, sadat mear automatisearre prosesmanagers binne dynamic и op oanfraach - populêrder. Ik hoopje dat it artikel nuttich wie.
DUP Benchmarkdiagram tafoege . As PHP-FPM-prosessen yn it ûnthâld binne, ferheget de prestaasjes op kosten fan ûnthâldferbrûk wêr't se sitte en wachtsje. Fyn de bêste opsje foar josels.
Boarne: www.habr.com