PHP-FPM સેટઅપ: મહત્તમ પ્રદર્શન માટે pm સ્ટેટિકનો ઉપયોગ કરો

આ લેખનું અસંપાદિત સંસ્કરણ મૂળરૂપે પ્રકાશિત થયું હતું haydenjames.io અને તેણીની પરવાનગી સાથે અહીં પ્રકાશિત લેખક.

હું તમને ટૂંકમાં કહીશ કે થ્રુપુટ વધારવા, લેટન્સી ઘટાડવા અને CPU અને મેમરીનો વધુ સતત ઉપયોગ કરવા માટે PHP-FPM ને ​​કેવી રીતે શ્રેષ્ઠ રીતે ગોઠવવું. મૂળભૂત રીતે, PHP-FPM માં PM (પ્રોસેસ મેનેજર) લાઇન છે ગતિશીલ, અને જો તમારી પાસે પૂરતી મેમરી નથી, તો તે ઇન્સ્ટોલ કરવું વધુ સારું છે માંગ. ચાલો php.net દસ્તાવેજીકરણના આધારે 2 નિયંત્રણ વિકલ્પોની તુલના કરીએ અને જુઓ કે મારા મનપસંદ તેમનાથી કેવી રીતે અલગ છે સ્થિર ઉચ્ચ વોલ્યુમ ટ્રાફિક માટે pm:

pm = ગતિશીલ — ચાઇલ્ડ પ્રક્રિયાઓની સંખ્યા નીચેના નિર્દેશોના આધારે ગતિશીલ રીતે ગોઠવેલ છે: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand - પ્રક્રિયાઓ માંગ પર બનાવવામાં આવે છે (જ્યારે સેવા શરૂ થાય ત્યારે pm.start_servers લૉન્ચ કરવામાં આવે છે ત્યારે ગતિશીલ બનાવટના વિરોધમાં).
pm = સ્થિર — બાળ પ્રક્રિયાઓની સંખ્યા નિશ્ચિત છે અને પરિમાણ દ્વારા સૂચવવામાં આવે છે pm.max_children.

વિગતો માટે, જુઓ વૈશ્વિક નિર્દેશોની સંપૂર્ણ સૂચિ php-fpm.conf.

PHP-FPM પ્રોસેસ મેનેજર અને CPU ફ્રીક્વન્સી કંટ્રોલર વચ્ચે સમાનતા

આ ઑફટોપિક લાગે છે, પરંતુ હું આને PHP-FPM રૂપરેખાંકનના વિષય સાથે લિંક કરવા જઈ રહ્યો છું. લેપટોપ, વર્ચ્યુઅલ મશીન અથવા સમર્પિત સર્વર પર - જેમણે ઓછામાં ઓછા એક વખત પ્રોસેસરની મંદીનો અનુભવ કર્યો નથી. CPU ફ્રીક્વન્સી સ્કેલિંગ યાદ છે? માટે આ વિકલ્પો ઉપલબ્ધ છે nix અને Windows પ્રોસેસર થ્રોટલ સેટિંગને બદલીને સિસ્ટમની કામગીરી અને પ્રતિભાવને સુધારી શકે છે માંગ પર પ્રદર્શન*. આ વખતે, ચાલો વર્ણનોની તુલના કરીએ અને સમાનતાઓ જોઈએ:

ગવર્નર = માંગ - વર્તમાન લોડ પર આધાર રાખીને પ્રોસેસર આવર્તનનું ગતિશીલ સ્કેલિંગ. ઝડપથી મહત્તમ આવર્તન પર જાય છે અને પછી નિષ્ક્રિયતાના સમયગાળામાં વધારો થતાં તે ઘટાડે છે.
ગવર્નર=રૂઢિચુસ્ત= વર્તમાન લોડ પર આધાર રાખીને ગતિશીલ આવર્તન સ્કેલિંગ. ઓનડિમાન્ડ કરતાં આવર્તન વધુ સરળતાથી વધે છે અને ઘટાડે છે.
ગવર્નર = કામગીરી - આવર્તન હંમેશા મહત્તમ છે.

વિગતો માટે, જુઓ પ્રોસેસર ફ્રીક્વન્સી રેગ્યુલેટર પરિમાણોની સંપૂર્ણ સૂચિ.

સમાનતાઓ જુઓ? હું તમને સમજાવવા માટે આ સરખામણી બતાવવા માંગતો હતો કે તેનો ઉપયોગ કરવો શ્રેષ્ઠ છે pm સ્થિર PHP-FPM માટે.

પ્રોસેસર રેગ્યુલેટર પેરામીટર માટે કામગીરી પ્રભાવને સુરક્ષિત રીતે વધારવામાં મદદ કરે છે કારણ કે તે સર્વરની CPU મર્યાદા પર લગભગ સંપૂર્ણપણે નિર્ભર છે. આ ઉપરાંત, અલબત્ત, તાપમાન, બેટરી ચાર્જ (લેપટોપમાં) અને સતત 100% પર પ્રોસેસરને ચલાવવાની અન્ય આડઅસરો જેવા પરિબળો પણ છે. પર્ફોર્મન્સ સેટિંગ પ્રોસેસરની સૌથી ઝડપી કામગીરીને સુનિશ્ચિત કરે છે. વાંચો, ઉદાહરણ તરીકે, વિશે Raspberry Pi માં force_turbo પેરામીટર, જેની સાથે RPi પેનલ રેગ્યુલેટરનો ઉપયોગ કરશે કામગીરી, જ્યાં ઓછી CPU ઘડિયાળ ગતિને કારણે પ્રદર્શન સુધારણા વધુ ધ્યાનપાત્ર હશે.

મહત્તમ સર્વર પ્રદર્શન હાંસલ કરવા માટે pm સ્ટેટિકનો ઉપયોગ કરવો

PHP-FPM વિકલ્પ pm સ્થિર મોટે ભાગે સર્વર પરની ફ્રી મેમરી પર આધાર રાખે છે. જો મેમરી ઓછી હોય, તો તે પસંદ કરવાનું વધુ સારું છે માંગ અથવા ગતિશીલ. બીજી બાજુ, જો તમારી પાસે મેમરી હોય, તો તમે pm સેટ કરીને PHP પ્રોસેસ મેનેજર ઓવરહેડને ટાળી શકો છો સ્થિર મહત્તમ સર્વર ક્ષમતા સુધી. બીજા શબ્દોમાં કહીએ તો, જો બધું સારી રીતે ગણવામાં આવે છે, તો તમારે સ્થાપિત કરવાની જરૂર છે pm.static PHP-FPM પ્રક્રિયાઓના મહત્તમ વોલ્યુમ સુધી કે જે ચલાવી શકાય છે, ઓછી મેમરી અથવા કેશ સાથે સમસ્યાઓ બનાવ્યા વિના. પરંતુ એટલું ઊંચું નથી કે તે પ્રોસેસરોને દબાવી દે છે અને એક્ઝિક્યુટ થવાની રાહ જોઈ રહેલા PHP-FPM ઑપરેશન્સનો સમૂહ એકઠા કરે છે..

ઉપરના સ્ક્રીનશોટમાં, સર્વર પાસે છે pm = સ્થિર અને pm.max_children = 100, અને આ ઉપલબ્ધ 10 માંથી આશરે 32 GB લે છે. હાઇલાઇટ કરેલ કૉલમ પર ધ્યાન આપો, અહીં બધું સ્પષ્ટ છે. આ સ્ક્રીનશૉટમાં ગૂગલ ઍનલિટિક્સમાં લગભગ 200 સક્રિય વપરાશકર્તાઓ (60 સેકન્ડથી વધુ) હતા. આ સ્તરે, આશરે 70% PHP-FPM ચાઇલ્ડ પ્રક્રિયાઓ હજુ પણ નિષ્ક્રિય છે. આનો અર્થ એ છે કે PHP-FPM વર્તમાન ટ્રાફિકને ધ્યાનમાં લીધા વિના હંમેશા સર્વર સંસાધનોની મહત્તમ રકમ પર સેટ છે. નિષ્ક્રિય પ્રક્રિયા ટ્રાફિકની ટોચની રાહ જુએ છે અને તરત જ પ્રતિસાદ આપે છે. તમારે ત્યાં સુધી રાહ જોવાની જરૂર નથી pm બાળ પ્રક્રિયાઓ બનાવશે અને પછી જ્યારે સમયગાળો સમાપ્ત થાય ત્યારે તેને સમાપ્ત કરશે pm.process_idle_timeout. મેં મૂલ્ય ખૂબ ઊંચા પર સેટ કર્યું pm.max_requestsકારણ કે આ એક કાર્યરત સર્વર છે જેમાં PHP માં કોઈ મેમરી લીક નથી. તમે ઇન્સ્ટોલ કરી શકો છો pm.max_requests = 0 જો તમે વર્તમાન અને ભાવિ PHP સ્ક્રિપ્ટ્સમાં સંપૂર્ણ વિશ્વાસ ધરાવો છો તો સ્ટેટિક સાથે. પરંતુ સમય જતાં સ્ક્રિપ્ટોને ફરીથી ચલાવવું વધુ સારું છે. મોટી સંખ્યામાં વિનંતીઓ સેટ કરો, કારણ કે અમે બિનજરૂરી pm ખર્ચ ટાળવા માંગીએ છીએ. ઉદાહરણ તરીકે, ઓછામાં ઓછું pm.max_requests = 1000 - જથ્થા પર આધાર રાખીને pm.max_children અને પ્રતિ સેકન્ડ વિનંતીઓની સંખ્યા.

સ્ક્રીનશોટ આદેશ બતાવે છે Linux ટોચ, u (વપરાશકર્તા) અને PHP-FPM વપરાશકર્તાનામ દ્વારા ફિલ્ટર કરેલ. ફક્ત પ્રથમ 50 અથવા તેથી વધુ પ્રક્રિયાઓ બતાવવામાં આવી છે (મેં બરાબર ગણી નથી), પરંતુ આવશ્યકપણે ટોચના આંકડાઓ બતાવે છે જે ટર્મિનલ વિંડોમાં ફિટ છે. આ કિસ્સામાં % CPU (% CPU) દ્વારા સૉર્ટ કરેલ છે. બધી 100 PHP-FPM પ્રક્રિયાઓ જોવા માટે, આદેશ ચલાવો:

top -bn1 | grep php-fpm

pm ઓનડિમાન્ડ અને ડાયનેમિકનો ઉપયોગ ક્યારે કરવો

જો તમે પીએમનો ઉપયોગ કરો છો ગતિશીલ, આના જેવી ભૂલો થાય છે:

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 children

પેરામીટર બદલવાનો પ્રયાસ કરો, ભૂલ દૂર થશે નહીં, જેમ કે સર્વરફોલ્ટ પર આ પોસ્ટમાં વર્ણવેલ છે. આ કિસ્સામાં, pm.min મૂલ્ય ખૂબ નાનું હતું, અને વેબ ટ્રાફિક ખૂબ જ બદલાય છે અને તેમાં ઉચ્ચ શિખરો અને ઊંડી ખીણો હોવાથી, pm ને યોગ્ય રીતે સમાયોજિત કરવું મુશ્કેલ છે. ગતિશીલ. સામાન્ય રીતે pm નો ઉપયોગ થાય છે માંગ, સમાન પોસ્ટમાં સલાહ આપવામાં આવી છે. પરંતુ આ વધુ ખરાબ છે, કારણ કે માંગ જ્યારે ટ્રાફિક ઓછો અથવા ઓછો હોય ત્યારે નિષ્ક્રિય પ્રક્રિયાઓને શૂન્ય પર સમાપ્ત કરે છે, અને તમે હજી પણ બદલાતા ટ્રાફિકના ઓવરહેડ સાથે સમાપ્ત થશો. જ્યાં સુધી, અલબત્ત, તમે એક વિશાળ પ્રતીક્ષા સમય સેટ કરો છો. અને પછી તેનો ઉપયોગ કરવો વધુ સારું છે pm.static + ઉચ્ચ સંખ્યા pm.max_requests.

PM ગતિશીલ અને ખાસ કરીને માંગ જો તમારી પાસે બહુવિધ PHP-FPM પૂલ હોય તો તે કામમાં આવી શકે છે. ઉદાહરણ તરીકે, તમે વિવિધ પુલમાં બહુવિધ cPanel એકાઉન્ટ્સ અથવા બહુવિધ વેબસાઇટ્સ હોસ્ટ કરો છો. મારી પાસે 100+ cpanel એકાઉન્ટ્સ અને લગભગ 200 ડોમેન્સ સાથેનું સર્વર છે, અને pm.static અથવા ડાયનેમિક પણ મને બચાવશે નહીં. તમારે અહીં જરૂર છે માંગ, છેવટે, બે તૃતીયાંશ કરતાં વધુ વેબસાઇટ્સ થોડો અથવા કોઈ ટ્રાફિક મેળવે છે, અને સાથે માંગ બધી બાળ પ્રક્રિયાઓ બંધ થઈ જશે, જે આપણને ઘણી મેમરી બચાવશે! સદનસીબે, cPanel વિકાસકર્તાઓએ આની નોંધ લીધી અને મૂલ્યને ડિફોલ્ટ પર સેટ કર્યું માંગ. પહેલાં, જ્યારે ડિફોલ્ટ હતું ગતિશીલ, PHP-FPM વ્યસ્ત વહેંચાયેલ સર્વરો માટે બિલકુલ યોગ્ય ન હતું. ઘણાએ ઉપયોગ કર્યો છે suPHP, કારણ કે pm ગતિશીલ નિષ્ક્રિય પૂલ અને cPanel PHP-FPM એકાઉન્ટ્સ સાથે પણ મેમરીનો વપરાશ કર્યો. મોટે ભાગે, જો ટ્રાફિક સારો હોય, તો તમને મોટી સંખ્યામાં PHP-FPM પૂલ (શેર કરેલ હોસ્ટિંગ) ધરાવતા સર્વર પર હોસ્ટ કરવામાં આવશે નહીં.

નિષ્કર્ષ

જો તમે PHP-FPM નો ઉપયોગ કરી રહ્યા છો અને તમારો ટ્રાફિક ભારે છે, તો પ્રક્રિયા સંચાલકો માંગ и ગતિશીલ PHP-FPM માટે તેમના અંતર્ગત ઓવરહેડને કારણે મર્યાદિત થ્રુપુટ હશે. તમારી સિસ્ટમને સમજો અને મહત્તમ સર્વર ક્ષમતા અનુસાર PHP-FPM પ્રક્રિયાઓને ગોઠવો. પ્રથમ સેટ pm.max_children મહત્તમ pm વપરાશ પર આધાર રાખીને ગતિશીલ અથવા માંગ, અને પછી આ મૂલ્યને એવા સ્તર સુધી વધારો કે જ્યાં મેમરી અને પ્રોસેસર ઓવરલોડ થયા વિના કામ કરશે. તમે તેની સાથે નોટિસ કરશો pm સ્થિર, તમારી પાસે મેમરીમાં બધું જ હોવાથી, ટ્રાફિક સ્પાઇક્સ સમય જતાં ઓછા CPU સ્પાઇક્સનું કારણ બનશે, અને સર્વર અને CPU લોડ એવરેજ લેવલ આઉટ થશે. સરેરાશ PHP-FPM પ્રક્રિયા કદ વેબ સર્વર પર આધાર રાખે છે અને મેન્યુઅલ રૂપરેખાંકનની જરૂર છે, તેથી વધુ સ્વચાલિત પ્રક્રિયા સંચાલકો ગતિશીલ и માંગ - વધુ લોકપ્રિય. મને આશા છે કે લેખ ઉપયોગી હતો.

યુપીડી બેન્ચમાર્ક ચાર્ટ ઉમેર્યો ab. જો PHP-FPM પ્રક્રિયાઓ મેમરીમાં હોય, તો તેઓ જ્યાં બેસીને રાહ જુએ છે ત્યાં મેમરી વપરાશના ભોગે કામગીરી વધે છે. તમારા માટે શ્રેષ્ઠ વિકલ્પ શોધો.

સોર્સ: www.habr.com