Optimizimi i PHP-FPM për Performancë të Lartë

PHP është kudo dhe është gjuha që vendoset më gjerësisht në Web Internet.


Sidoqoftë, nuk dihet saktësisht për aftësitë e tij të larta të performancës, veçanërisht kur bëhet fjalë për sisteme shumë të njëkohshme. Dhe kjo është arsyeja që për raste të tilla të përdorimit të specializuar, gjuhë të tilla si Node (po, unë e di, nuk është gjuhë), Go dhe Elixir po marrin përsipër.

Thënë kjo, ka një LOT që mund të bësh për të përmirësuar performancën PHP në serverin tuaj. Ky artikull përqendrohet në anën php-fpm të gjërave, që është mënyra natyrale për të konfiguruar në serverin tuaj nëse përdorni Nginx.

Në rast se e dini se çfarë është php-fpm, mos ngurroni të hidheni te seksioni për optimizimin.

Farë është php-fpm?

Jo shumë zhvillues janë të interesuar në DevOps anë e gjërave, dhe madje edhe në mesin e atyre që bëjnë, shumë pak e dinë se çfarë po ndodh nën kapuç. Shtë interesante, kur shfletuesi dërgon një kërkesë te një server që funksionon PHP, nuk është PHP ajo që krijon pikën e kontaktit të parë; në vend të kësaj, është serveri HTTP, kryesorët e të cilëve janë Apache dhe Nginx. Këta “serverë në internet” më pas duhet të vendosin se si të lidhen me PHP, dhe t’i kalojnë llojin e kërkesës, të dhënat dhe titujt e tij..

Cikli i kërkesës-përgjigjes në rastin e PHP (Kredia e figurës: ProinerTech)

Në aplikacionet moderne PHP, pjesa “gjeni skedarin” më lart është indeksi.php, i cili është konfiguruar që serveri të delegojë të gjitha kërkesat në.

Tani, sesi saktësisht lidhet serveri në internet me PHP ka evoluar, dhe ky artikull do të shpërthejë në gjatësi nëse do të futeshim në të gjithë mprehtësinë. Por përafërsisht, gjatë kohës që Apache mbizotëroi si serveri në internet i zgjedhjes, PHP ishte një modul i përfshirë brenda serverit.

Kështu që, sa herë që merrej një kërkesë, serveri do të fillonte një proces të ri, i cili automatikisht do të përfshijë PHP, dhe do ta ekzekutojë atë. Kjo metodë u quajt mod_php, e shkurtër për “php si modul”. Kjo qasje kishte kufizimet e saj, të cilat Nginx i kapërceu me php-fpm.

Në php-fpm përgjegjësia e menaxhimit të PHP, proceset i takojnë programit PHP brenda serverit. Me fjalë të tjera, serveri në internet (Nginx, në rastin tonë), nuk interesohet se ku është PHP dhe si ngarkohet, për sa kohë që ai di të dërgojë dhe të marrë të dhëna nga ai. Nëse dëshironi, mund të mendoni për PHP në këtë rast si një server tjetër në vetvete, i cili menaxhon disa procese PHP për fëmijë për kërkesa në hyrje (pra, ne kemi kërkesën që të arrijmë në një server, i cili u pranua nga një server dhe kaloi në një server – goxha e çmendur! :-P).

Nëse keni realizuar ndonjë cilësim Nginx, ose madje thjesht keni pritur në to, do të takoni diçka të tillë:

vendndodhja ~ \ .php $
provo_files $ uri = 404;
fastcgi_split_path_info ^ (. + \. php) (/.+) $;
fastcgi_pass unix: /run/php/php7.2-fpm.sock;
indeksi fastcgi_index.php;
përfshijnë fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;
}

Linja për të cilën ne jemi të interesuar është kjo: fastcgi_pass unix: /run/php/php7.2-fpm.sock ;, e cila i thotë Nginx të komunikojë me procesin PHP përmes prizës me emrin php7.2-fpm.sock. Pra, për çdo kërkesë hyrëse, Nginx shkruan të dhëna përmes këtij skedari, dhe pasi të marrë rezultatin, i dërgon përsëri në shfletues.

Edhe një herë, duhet të theksoj se kjo nuk është fotografia më e plotë ose më e saktë e asaj që vazhdon, por është plotësisht e saktë për shumicën e detyrave të DevOps.

Me këtë mënjanë, le të kujtojmë ato që kemi mësuar deri më tani:

  • PHP nuk merr direkt kërkesa të dërguara nga shfletuesit. Serverët në internet si Nginx së pari i përgjojnë këta.
  • Web serveri di si të lidhet me procesin e PHP dhe i kalon të gjitha të dhënat e kërkesës (fjalë për fjalë ngjit gjithçka) në PHP.
  • Kur PHP ka mbaruar të bëjë pjesën e vet, ai dërgon përgjigjen përsëri në serverin në internet, i cili e dërgon atë përsëri tek klienti (ose shfletuesi, në shumicën e rasteve).

Ose grafikisht:

Si funksionojnë PHP dhe Nginx së bashku (Kredia e figurës: DataDog)

E madhe deri më tani, por tani vjen pyetja milion dollarësh: çfarë saktësisht është PHP-FPM?

Pjesa “FPM” në PHP nënkupton “Menaxherin e Procesit të Shpejtë”, i cili është vetëm një mënyrë e zbukuruar për të thënë që PHP që funksionon në një server nuk është një proces i vetëm, por përkundrazi disa procese PHP që janë pjellë, kontrollues dhe vrarë. off nga ky menaxher i procesit FPM. Thisshtë ky menaxher i procesit që serveri në internet i kalon kërkesat.

PHP-FPM është një vrimë e tërë lepuri në vetvete, kështu që ndjehuni të lirë të eksploroni nëse dëshironi, por për qëllimet tona, këtë shpjegim shumë do ta bëni. ��

Pse të zgjedh php-fpm?

Atëherë, pse të shqetësohesh për gjithë këtë valle kur gjërat po funksionojnë në rregull? Pse jo vetëm t’i lëmë gjërat ashtu siç janë.

Ironikisht, kjo është pikërisht këshilla që unë jap për shumicën e rasteve të përdorimit. Nëse konfigurimi juaj po funksionon mirë dhe nuk ka raste të përdorimit të jashtëzakonshëm, përdorni parazgjedhjet. Sidoqoftë, nëse po kërkoni të shkallëzoni përtej një makine të vetme, atëherë shtrydhja e maksimumit nga një është thelbësore pasi mund të shkurtojë faturat e serverit në gjysmë (ose edhe më shumë!).

Një tjetër gjë për të kuptuar është se Nginx ishte ndërtuar për trajtimin e ngarkesave të mëdha. Shtë në gjendje të trajtojë mijëra lidhje në të njëjtën kohë, por nëse e njëjta gjë nuk është e vërtetë për konfigurimin tuaj PHP, thjesht do të humbni burimet pasi Nginx do të duhet të presë që PHP të përfundojë me procesin aktual dhe të pranojë tjetër, përfundimisht negativisht çdo avantazh që Nginx u ndërtua për të siguruar!

Pra, me atë pa mbarim, le të shohim se çfarë saktësisht do të ndryshojmë kur përpiqemi të zgjedhim php-fpm.

Si të zgjedh PHP-FPM?

Vendndodhja e skedarit të konfigurimit për php-fpm mund të ndryshojë në server, kështu që do të duhet të bëni disa hulumtime për gjetjen e tij. Mund të përdorni komandën find nëse është në UNIX. Në Ubuntu tim, shtegu është /etc/php/7.2/fpm/php-fpm.conf. 7.2 është, natyrisht, versioni i PHP që po ekzekutoj.

Ja si duken rreshtat e parë të kësaj skedari:

;;;;;;;;;;;;;;;;;;;;;
; Konfigurimi i FPM;
;;;;;;;;;;;;;;;;;;;;;

; Të gjitha shtigjet relative në këtë skedar konfigurimi janë në lidhje me instalimin e PHP
; parashtesë (/ usr). Kjo parashtesë mund të ndryshohet në mënyrë dinamike duke përdorur
; Argumenti ‘-p’ nga linja e komandës.

;;;;;;;;;;;;;;;;;;
; Opsionet globale;
;;;;;;;;;;;;;;;;;;

[Globale]
; Dosje Pid
; Shënim: parashtesa parazgjedhur është / var
; Vlera e paracaktuar: asnjë
pid = /run/php/php7.2-fpm.pid

; Skedari i regjistrit të gabimeve
; Nëse është caktuar "syslog", log është dërguar në syslogd në vend se të shkruhet
; në një skedar lokal.
; Shënim: parashtesa parazgjedhur është / var
; Vlera e paracaktuar: log / php-fpm.log
gabim_log = /var/log/php7.2-fpm.log

Disa gjëra duhet të jenë menjëherë të qarta: pid line = /run/php/php7.2-fpm.pid na tregon se cili skedar përmban iden e procesit të procesit php-fpm.

Ne gjithashtu shohim që /var/log/php7.2-fpm.log është vendi ku php-fpm do të ruajë regjistrat e tij.

Brenda këtij skedari, shtoni tre ndryshore të tjera si kjo:

emergjente_restart_threshold 10
emergjent_restart_interval 1m
process_control_time 10s

Dy cilësimet e para janë paralajmëruese dhe po i tregojnë procesit php-fpm që nëse dhjetë procese të fëmijëve dështojnë brenda një minutë, procesi kryesor php-fpm duhet të rindizet vetë.

Kjo mund të mos duket e fortë, por PHP është një proces jetëshkurtër që bën rrjedhje të kujtesës, kështu që rifillimi i procesit kryesor në raste të dështimit të lartë mund të zgjidhë shumë probleme.

Mundësia e tretë, process_control_timeout, i tregon fëmijës proceset që të presin këtë shumë kohë përpara se të ekzekutojnë sinjalin e marrë nga procesi i prindërve. Kjo është e dobishme në rastet kur proceset e fëmijës janë në mes të diçkaje kur proceset mëmë dërgojnë një sinjal KILL, për shembull. Me dhjetë sekonda në dorë, ata do të kenë një shans më të mirë për të përfunduar detyrat e tyre dhe për të dalë me mirësi.

Pruditërisht, kjo nuk është mishi i konfigurimit të php-fpm! Kjo sepse për të shërbyer kërkesa në internet, php-fpm krijon një grup të ri të proceseve, i cili do të ketë një konfigurim të veçantë. Në rastin tim, emri i pishinës doli të ishte www dhe skedari që doja të redaktoja ishte /etc/php/7.2/fpm/pool.d/www.conf.

Le të shohim se si fillon kjo skedar:

; Filloni një pishinë të re me emrin ‘www’.
; pishina e ndryshueshme $ mund të përdoret në çdo direktivë dhe do të zëvendësohet me
; emri i pishinës (‘www’ këtu)
[Www]

; Për prefiksin e pishinës
; Ai vlen vetëm për direktivat e mëposhtme:
; – ‘hyrje.log’
; – ‘ngadale’
; – ‘degjo’ (unixsocket)
; – ‘zhurmë’
; – ‘chdir’
; – ‘php_values’
; – ‘php_admin_values’
; Kur nuk vendoset, prefiksi global (ose / usr) zbatohet në vend.
; Shënim: Kjo direktivë gjithashtu mund të jetë në lidhje me parashtesën globale.
; Vlera e paracaktuar: asnjë
; parashtesë = / shteg / drejt / pishinave / $ pishinë

; Përdoruesi / grupi i proceseve unix
; Shënim: Përdoruesi është i detyrueshëm. Nëse grupi nuk është i vendosur, grupi i paracaktuar i përdoruesit
; do të përdoret.
përdoruesi = www-data
grupi = www-data

Një vështrim i shpejtë në fundin e copëzës së mësipërme zgjidh enigmën se pse procesi i serverit funksionon si të dhëna www. Nëse keni hasur në çështjet e lejes së skedarit kur vendosni uebfaqen tuaj, ka të ngjarë të keni ndryshuar pronarin ose grupin e drejtorisë në të dhëna www, duke lejuar kështu që procesi PHP të jetë në gjendje të shkruajë në skedarë log dhe të ngarkojë dokumente, etj.

Më në fund, arrijmë në burimin e çështjes, caktimin e menaxherit të procesit (pasdite). Në përgjithësi, ju do t’i shihni standardet si diçka e tillë:

pasdite = dinamike
pasdite.max_children = 5
pasdite.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

Pra, çfarë bëndinamik“Këtu do të thotë? Unë mendoj se dokumentet zyrtare e shpjegojnë më së miri këtë (dua të them, kjo tashmë duhet të jetë pjesë e skedarit që jeni duke redaktuar, por unë i kam riprodhuar këtu vetëm në rast se nuk është):

; Zgjidhni se si menaxheri i procesit do të kontrollojë numrin e proceseve të fëmijëve.
; Vlerat e mundshme:
; statike – një numër fiks (pm.max_children) i proceseve të fëmijëve;
; dinamike – numri i proceseve të fëmijëve vendoset dinamikisht bazuar në
; direktivat vijuese. Me këtë menaxhim të procesit, do të ketë
; gjithnjë së paku 1 fëmijë.
; pm.max_children – numri maksimal i fëmijëve që munden
; të jetë i gjallë në të njëjtën kohë.
; pm.start_servers – numri i fëmijëve të krijuar gjatë fillimit.
; pm.min_spare_servers – numri minimal i fëmijëve në ‘punë të papunë’
; shtet (në pritje të procesimit). Nëse numri
; e proceseve ‘boshe’ është më pak se kjo
; numri atëherë do të krijohen disa fëmijë.
; pm.max_spare_servers – numri maksimal i fëmijëve në id boshe ’
; shtet (në pritje të procesimit). Nëse numri
; e proceseve ‘boshe’ është më e madhe se kjo
; numri atëherë disa fëmijë do të vriten.
; ondemand – asnjë fëmijë nuk krijohen gjatë fillimit. Fëmijët do të forcohen kur
; kërkesat e reja do të lidhen. Përdoren parametri i mëposhtëm:
; pm.max_children – numri maksimal i fëmijëve që
; mund të jetë i gjallë në të njëjtën kohë.
; pm.process_idle_timeout – Numri i sekondave pas së cilës
; një proces boshe do të vritet.
; Shënim: Kjo vlerë është e detyrueshme.

Pra, ne shohim se ekzistojnë tre vlera të mundshme:

  • i pandryshueshëm: Një numër i caktuar i proceseve PHP do të ruhet pa marrë parasysh çfarë.
  • dinamik: Ne duhet të specifikojmë minimumin dhe numrin maksimal të proceseve që php-fpm do t’i mbajë gjallë në çdo moment të caktuar në kohë.
  • OnDemand: Proceset krijohen dhe shkatërrohen, mirë, sipas kërkesës.

Pra, si kanë rëndësi këto parametra?

Me fjalë të thjeshta, nëse keni një uebfaqe me trafik të ulët, vendosja “dinamike” është humbje e burimeve shumicën e kohës. Duke supozuar se ju keni pm.min_spare_servers të vendosur në 3, tre procese PHP do të krijohen dhe mirëmbahen edhe kur nuk ka trafik në faqen e internetit. Në raste të tilla, “ondemand” është një mundësi më e mirë, duke e lënë sistemin të vendosë se kur do të fillojnë proceset e reja.

Nga ana tjetër, faqet e internetit që merren me sasi të mëdha të trafikut ose që duhet të përgjigjen shpejt, do të ndëshkohen në këtë mjedis. Krijimi i një procesi të ri PHP, duke e bërë atë pjesë të një pishine, dhe monitorimin e tij, është shtesë e sipërme që shmanget më së miri.

Përdorimi i pm = statike rregullon numrin e proceseve të fëmijëve, duke lejuar që burimet maksimale të sistemit të përdoren në shërbimin e kërkesave sesa në menaxhimin e PHP. Nëse shkoni në këtë rrugë, kini kujdes që ka udhëzimet dhe pengesat e saj. Një artikull mjaft i dendur, por shumë i dobishëm për të këtu.

Fjalët përfundimtare

Meqenëse artikujt mbi performancën e uebit mund të shkaktojnë luftëra ose të shërbejnë për të hutuar njerëzit, unë mendoj se disa fjalë janë në rregull para se të mbyllim këtë artikull. Akordimi i performancës ka të bëjë me mendimet dhe artet e errëta, sa është njohja e sistemit.

Edhe nëse i dini të gjitha cilësimet e php-fpm nga zemra, suksesi nuk është i garantuar. Nëse nuk keni të dhëna për ekzistencën e php-fpm, atëherë nuk do të keni nevojë të humbni kohë duke u shqetësuar për të. Vetëm vazhdoni të bëni atë që tashmë po bëni dhe vazhdoni.

Në të njëjtën kohë, shmangni fundin e të qenit junkie të performancës. Po, ju mund të merrni një performancë edhe më të mirë duke kompensuar PHP nga e para dhe duke hequr të gjitha modulet që nuk do të përdorni, por kjo qasje nuk është mjaft e shëndoshë në mjediset e prodhimit. Ideja e tërë për të optimizuar diçka është të hidhni një sy nëse nevojat tuaja ndryshojnë nga standardet (të cilat ata rrallë bëjnë!), Dhe të bëni ndryshime të vogla sipas nevojës.

Nëse nuk jeni të gatshëm të shpenzoni kohë për të optimizuar serverët tuaj PHP, atëherë mund të merrni në konsideratë përdorimin e një platforme të besueshme si Kinsta të cilët kujdesen për optimizimin e performancës dhe sigurinë.

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