PHP-FPM सेटअप: अधिकतम प्रदर्शनको लागि pm स्थिर प्रयोग गर्नुहोस्

यस लेखको एक असंपादित संस्करण मूल रूपमा प्रकाशित भएको थियो haydenjames.io र उनको अनुमति संग यहाँ प्रकाशित लेखक.

थ्रुपुट बढाउन, विलम्बता कम गर्न, र सीपीयू र मेमोरीलाई निरन्तर रूपमा प्रयोग गर्नको लागि 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 = माग - प्रक्रियाहरू मागमा सिर्जना गरिन्छ (गतिशील सिर्जनाको विपरित, जब pm.start_servers सेवा सुरु हुन्छ)।
pm = स्थिर - बाल प्रक्रियाहरूको संख्या निश्चित छ र प्यारामिटर द्वारा संकेत गरिएको छ pm.max_children.

विवरणहरूको लागि, हेर्नुहोस् विश्वव्यापी निर्देशनहरूको पूर्ण सूची php-fpm.conf.

PHP-FPM प्रक्रिया प्रबन्धक र CPU फ्रिक्वेन्सी नियन्त्रक बीच समानताहरू

यो अफटोपिक जस्तो लाग्न सक्छ, तर म यसलाई PHP-FPM कन्फिगरेसनको शीर्षकमा लिङ्क गर्न जाँदैछु। ल्यापटप, भर्चुअल मेसिन वा समर्पित सर्भरमा - कम्तिमा एक पटक प्रोसेसर सुस्त हुने अनुभव कसले गरेको छैन? CPU फ्रिक्वेन्सी स्केलिंग सम्झना छ? यी विकल्पहरू उपलब्ध छन् nix र Windows ले प्रोसेसर थ्रोटल सेटिङ परिवर्तन गरेर प्रणाली प्रदर्शन र प्रतिक्रिया सुधार गर्न सक्छ माग बमोजिम मा प्रदर्शन *। यस पटक, वर्णनहरू तुलना गरौं र समानताहरू हेरौं:

गभर्नर = माग - हालको लोडमा निर्भर गर्दै प्रोसेसर फ्रिक्वेन्सीको गतिशील स्केलिंग। द्रुत रूपमा अधिकतम फ्रिक्वेन्सीमा जान्छ र त्यसपछि निष्क्रियताको अवधि बढ्दै जाँदा यसलाई घटाउँछ।
गभर्नर = रूढ़िवादी = हालको लोडमा निर्भर गर्दै गतिशील फ्रिक्वेन्सी स्केलिंग। ondemand भन्दा धेरै सहज रूपमा फ्रिक्वेन्सी बढाउँछ र घटाउँछ।
राज्यपाल = कार्यसम्पादन - आवृत्ति सधैं अधिकतम छ।

विवरणहरूको लागि, हेर्नुहोस् प्रोसेसर फ्रिक्वेन्सी नियामक प्यारामिटरहरूको पूर्ण सूची.

समानताहरू हेर्नुहोस्? म यो तुलना देखाउन चाहन्छु कि यो प्रयोग गर्न को लागी सबै भन्दा राम्रो छ भनेर विश्वस्त पार्न pm स्थिर PHP-FPM को लागी।

प्रोसेसर नियामक प्यारामिटर लागि प्रदर्शन सुरक्षित रूपमा कार्यसम्पादन बढाउन मद्दत गर्दछ किनभने यो लगभग पूर्ण रूपमा सर्भरको CPU सीमामा निर्भर छ। यसका अतिरिक्त, निस्सन्देह, त्यहाँ तापमान, ब्याट्री चार्ज (ल्यापटपमा) र 100% मा लगातार प्रोसेसर चलाउँदा अन्य साइड इफेक्टहरू पनि छन्। प्रदर्शन सेटिङले सबैभन्दा छिटो प्रोसेसर प्रदर्शन सुनिश्चित गर्दछ। पढ्नुहोस्, उदाहरणका लागि, बारे Raspberry Pi मा force_turbo प्यारामिटर, जसको साथ आरपीआई प्यानलले नियामक प्रयोग गर्नेछ प्रदर्शन, जहाँ कम CPU घडी गतिको कारण कार्यसम्पादन सुधार अधिक ध्यान दिनेछ।

अधिकतम सर्भर प्रदर्शन प्राप्त गर्न pm स्थिर प्रयोग गर्दै

PHP-FPM विकल्प 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 र प्रति सेकेन्ड अनुरोधहरूको संख्या।

स्क्रिनसटले आदेश देखाउँछ लिनक्स शीर्ष, u (प्रयोगकर्ता) र PHP-FPM प्रयोगकर्ता नाम द्वारा फिल्टर गरिएको। केवल पहिलो 50 वा सो प्रक्रियाहरू देखाइन्छ (मैले ठ्याक्कै गणना गरेन), तर अनिवार्य रूपमा शीर्षले टर्मिनल सञ्झ्यालमा फिट हुने शीर्ष तथ्याङ्कहरू देखाउँछ। यस अवस्थामा % CPU (% CPU) द्वारा क्रमबद्ध। सबै 100 PHP-FPM प्रक्रियाहरू हेर्न, आदेश चलाउनुहोस्:

top -bn1 | grep php-fpm

pm ondemand र dynamic कहिले प्रयोग गर्ने

यदि तपाइँ 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 प्रक्रिया आकार वेब सर्भरमा निर्भर गर्दछ र म्यानुअल कन्फिगरेसन आवश्यक छ, त्यसैले अधिक स्वचालित प्रक्रिया प्रबन्धकहरू छन्। गतिशील и माग बमोजिम - अधिक लोकप्रिय। मलाई आशा छ लेख उपयोगी थियो।

DUP बेन्चमार्क चार्ट थपियो ab। यदि PHP-FPM प्रक्रियाहरू मेमोरीमा छन् भने, तिनीहरू बस्ने र पर्खने ठाउँमा मेमोरी खपतको खर्चमा प्रदर्शन बढ्छ। आफ्नो लागि उत्तम विकल्प खोज्नुहोस्।

स्रोत: www.habr.com