Versioni e paardakë që nuk janë redaktuar u publikuan për herë të parë në dhe po publikohet këtu me lejen e saj .
Në dy fjalë, do t'ju tregoj se si ta konfiguroni sa më mirë PHP-FPM për të rritur kapacitetin, reduktuar vonesën dhe përdorur më stabilisht burimet e procesorit dhe memorjen. Në mënyrë standarde, rreshti PM (menaxheri i proceseve) në PHP-FPM ka vlerën dinamike, ndërsa nëse ju mungon memoria, është më mirë të vendosni në kërkesë. Le të krahasojmë dy variantet e menaxhimit bazuar në dokumentacionin php.net dhe të shohim se çfarë i dallon nga menaxheri im i preferuar static pm për sasi të mëdha trafiku:
pm = dinamike â numri i proceseve fĂ«mijĂ« rregullohet dinamikisht nĂ« bazĂ« tĂ« drejtimeve tĂ« mĂ«poshtme: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = nĂ« kĂ«rkesĂ« â proceset krijohen sipas kĂ«rkesĂ«s (ndryshe nga krijimi dinamik, kur pm.start_servers aktivizohen gjatĂ« startit tĂ« shĂ«rbimit).
pm = statike â numri i proceseve fĂ«mijĂ« Ă«shtĂ« i fiksuar dhe Ă«shtĂ« i specifikuar nga pm.max_children.
PĂ«r detaje, shihni .
Ngjashmëritë e menaxherit të procesit PHP-FPM me rregullatorin e frekuencës së procesorit
Kjo mund të duket si një temë tjetër, por do ta lidhem me temën e konfigurimit të PHP-FPM. Kujtoni ndonjëherë kur procesori ndalon së funksionuari - në laptop, në një makinë virtuale ose në një server të dedikuar. A e kujtoni rregullimin e frekuencës së procesorit? Këto parametra, të disponueshëm për nix dhe Windows, mund të përmirësojnë performancën dhe shpejtësinë e reagimit të sistemit, nëse ndryshoni parametrin e rregullatorit të procesorit nga në kërkesë në performancë*. Tani le të krahasojmë përshkrimet dhe të shohim ngjashmëritë:
Rregullatori = nĂ« kĂ«rkesĂ« â rregullimi dinamik i frekuencĂ«s sĂ« procesorit nĂ« varĂ«si tĂ« ngarkesĂ«s aktuale. Shpejt kalon nĂ« frekuencĂ«n maksimale dhe pastaj e ul atĂ« kur intervalet e qetĂ«sisĂ« rriten.
Rregullatori = konservator = rregullimi dinamik i frekuencës në varësi të ngarkesës aktuale. Rrit dhe ul frekuencën më ngadalë se në kërkesë.
Rregullatori = performancĂ« â frekuenca gjithmonĂ« Ă«shtĂ« maksimale.
PĂ«r detaje, shihni .
A shihni ngjashmërinë? Doja të tregoja këtë krahasim për t'ju bindur se është më e mira të përdorni pm statike për PHP-FPM.
Për rregullatorin e procesorit, parametri performancë ndihmon për të rritur performancën në mënyrë të sigurt, sepse ajo varet thuajse tërësisht nga kufiri i procesorit të serverit. Përveç kësaj, natyrisht, ka disa faktorë të tjerë, si temperatura, ngarkesa e baterisë (në laptop) dhe efekte të tjera anësore të punës së vazhdueshme të procesorit në 100%. Konfigurimi i performancës siguron funksionimin më të shpejtë të procesorit. Lexoni, për shembull, për , me të cilin paneli RPi do të përdorë rregullatorin performancë, ku përmirësimi i performancës do të jetë më i dukshëm për shkak të frekuencës së ulët të CPU.
Përdorimi i pm static për të arritur performancën maksimale të serverit
Parametri PHP-FPM pm statike në masë të madhe varet nga memoria e lirë në server. Nëse ka pak memorie, është më mirë të zgjidhni në kërkesë ose dinamike. Nga ana tjetër, nëse keni memorie, mund të shmangni kostot e tepërta të menaxherit të procesit PHP, duke vendosur pm static në kapacitetin maksimal të serverit. Me fjalë të tjera, nëse të gjitha janë llogaritur mirë, duhet të vendosni pm.static në numrin maksimal të proceseve PHP-FPM që mund të ekzekutohen, pa krijuar probleme me mungesën e memories ose caches. Por jo kaq lartë sa të ngarkoni procesorët dhe të grumbulloni një mori operacionesh PHP-FPM që presin të ekzekutohen..
NĂ« skrin-shotin mĂ« sipĂ«r, nĂ« server Ă«shtĂ« vendosur pm = static dhe pm.max_children = 100, dhe kjo merr rreth 10 GB nga 32 tĂ« disponueshme. Vini re kolonat e theksuara, kĂ«tu gjithçka Ă«shtĂ« e qartĂ«. NĂ« kĂ«tĂ« skrin-shot kishte rreth 200 pĂ«rdorues aktivĂ« (mĂ« shumĂ« se 60 sekonda) nĂ« Google Analytics. NĂ« kĂ«tĂ« nivel rreth 70% e proceseve fĂ«mijĂ« PHP-FPM janĂ« akoma nĂ« pritje. Kjo do tĂ« thotĂ« se PHP-FPM Ă«shtĂ« gjithmonĂ« e vendosur nĂ« kapacitetin maksimal tĂ« burimeve tĂ« serverit pavarĂ«sisht nga trafiku aktual. Procesi nĂ« pritje pret pikun e trafikut dhe pĂ«rgjigjet menjĂ«herĂ«. Ju nuk keni nevojĂ« tĂ« prisni deri sa pm tĂ« krijojĂ« procese fĂ«mijĂ«, dhe pastaj t'i mbyllĂ« ato, kur skadon periudha pm.process_idle_timeout. Kam vendosur njĂ« vlerĂ« shumĂ« tĂ« madhe pĂ«r pm.max_requests, sepse ky Ă«shtĂ« njĂ« server funksional pa rrjedhje memorjeje nĂ« PHP. Ju mund tĂ« vendosni pm.max_requests = 0 me static, nĂ«se jeni plotĂ«sisht tĂ« sigurt pĂ«r skiptet e tanishme dhe ato tĂ« ardhshme PHP. Por Ă«shtĂ« mĂ« mirĂ« t'i rinit skiptet me kalimin e kohĂ«s. Vendosni njĂ« numĂ«r tĂ« madh kĂ«rkesash, sepse ne duam tĂ« shmangim kostot e tepĂ«rta pm. PĂ«r shembull, tĂ« paktĂ«n pm.max_requests = 1000 â nĂ« pĂ«rputhje me numrin pm.max_children dhe numrin e kĂ«rkesave pĂ«r sekondĂ«.
Në skrin-shot është treguar komanda , e filtruar sipas u (user) dhe emrit të përdoruesit PHP-FPM. Tregohet vetëm 50 proceset e para ose pak më shumë (nuk e kam numëruar saktësisht), por, në thelb, top tregon statistikën kryesore që vendoset në dritaren e terminalit. Në këtë rast me renditje sipas % CPU (%CPU). Për të parë të gjitha 100 proceset PHP-FPM, ekzekutoni komandën:
top -bn1 | grep php-fpmKur të përdoret pm ondemand dhe dynamic
Nëse përdoret pm dinamike, ndodhin gabime të tilla:
WARNING: [pool xxxx] duket e zënë (mund të duhet të rrisni pm.start_servers, ose pm.min/max_spare_servers), duke krijuar 32 fëmijë, ka 4 të papunë, dhe 59 fëmijë gjithsej;Provoni të ndryshoni parametrin, gabimi nuk do të zhduket, si . Në këtë rast, vlera pm.min ishte shumë e vogël, dhe pasi trafiku në internet ndryshon ndjeshëm dhe ka maja të larta dhe rënie të thella, është e vështirë ta konfiguroni saktësisht pm dinamike. Normalisht në këtë rast përdoret pm në kërkesë, . Por kjo është edhe më e keqe, pasi në kërkesë përfundon proceset e papërdorura deri në zero, kur traffiku është i vogël ose nuk ka, dhe në fund ju akoma do të vuani nga kostot gjatë ndryshimit të trafikut. Nëse, natyrisht, nuk keni vendosur një kohë pritjeje të madhe. Dhe atëherë është më mirë të përdorni pm.static + numër të lartë pm.max_requests.
PM dinamike dhe sidomos në kërkesë mund të jenë të dobishme, nëse keni disa pool PHP-FPM. Për shembull, po hostoni disa llogari cPanel ose disa faqe në internet në pika të ndryshme. Kam një server ku, le të themi, 100+ llogari cpanel dhe përafërsisht 200 domene, dhe pm.static ose madje dinamik nuk do të më shpëtonte. Këtu nevojitet vetëm në kërkesë, pasi më shumë se dy të tretat e faqeve në internet marrin pak trafik ose fare, dhe me në kërkesë të gjithë fëmijët do të ndalen, që do të kursejë shumë memorie! Fatmirësisht, zhvilluesit e cPanel e vunë re këtë dhe vendosën një vlerë standart në kërkesë. Më herët, kur vlera standarde ishte dinamike, PHP-FPM në përgjithësi nuk ishte i përshtatshëm për serverët e ngarkuar të përbashkët. Shumë përdornin suPHP, sepse pm dinamike consumonte memorie edhe kur pool dhe llogaritë cPanel PHP-FPM ishin të papërdorura. Me siguri, me trafik të mirë, nuk do të jeni në një server me një numër të madh pool PHP-FPM (hosting i përbashkët).
PĂ«rfundim
NĂ«se dĂ«shironi tĂ« pĂ«rdorni PHP-FPM dhe trafiku juaj Ă«shtĂ« serioz, menaxherĂ«t e proceseve nĂ« kĂ«rkesĂ« dhe dinamike pĂ«r PHP-FPM do tĂ« kufizojnĂ« kapacitetin pĂ«r shkak tĂ« kostove tĂ« tyre tĂ« natyrshme. Analizoni sistemin tuaj dhe konfiguroni proceset PHP-FPM sipas kapacitetit maksimal tĂ« serverit. Filloni duke caktuar pm.max_children sipas pĂ«rdorimit maksimal tĂ« pm dinamike ose nĂ« kĂ«rkesĂ«, dhe pastaj rriteni kĂ«tĂ« vlerĂ« deri nĂ« nivelin ku memoria dhe procesori do tĂ« funksionojnĂ« pa mbingarkesĂ« tĂ« tepruar. Do tĂ« vini re se me pm statike, njĂ« herĂ« qĂ« gjithçka ruhet nĂ« memory, shpĂ«rthimet e trafikut me kalimin e kohĂ«s do tĂ« shkaktojnĂ« mĂ« pak shpĂ«rthime pĂ«r procesorin, dhe mesataret e ngarkesĂ«s sĂ« serverit dhe procesorit do tĂ« stabilizohen. MadhĂ«sia mesatare e procesit PHP-FPM varet nga serveri web dhe kĂ«rkon konfigurim manual, prandaj menaxherĂ«t e proceseve mĂ« tĂ« automatizuar janĂ« dinamike dhe nĂ« kĂ«rkesĂ« â mĂ« tĂ« njohur. Shpresoj qĂ« artikulli tĂ« ketĂ« qenĂ« i dobishĂ«m.
UPD Diagrami i benchmark-ut është shtuar . Nëse proceset PHP-FPM janë në memory, performanca rritet për shkak të konsumit të memories, ku ato qëndrojnë dhe presin. Gjeni opsionin optimal për vete.
Burimi: habr.com
