नमस्कार, हेब्र! दो साल पहले हमने लिखा था कि कैसे हमने PHP 7.0 में स्विच किया और एक मिलियन डॉलर बचाया। हमारे लोड प्रोफाइल पर, नया संस्करण सीपीयू उपयोग में दोगुना कुशल था: जिस लोड का उपयोग हम ~ 600 सर्वरों के लिए करते थे, संक्रमण के बाद ~ 300 परोसना शुरू हुआ। नतीजतन, दो साल तक हमारे पास क्षमता का भंडार था।

लेकिन व्यस्तता बढ़ रही है। सक्रिय उपयोगकर्ताओं की संख्या लगातार बढ़ रही है। हम अपनी कार्यक्षमता में सुधार और विकास कर रहे हैं, जिसके लिए उपयोगकर्ता एप्लिकेशन में अधिक से अधिक समय बिताते हैं। और यह, बदले में, उन अनुरोधों की संख्या में परिलक्षित होता है, जो पिछले दो वर्षों में 2-2.5 गुना बढ़ गए हैं।

हमने खुद को ऐसी स्थिति में पाया जहां अनुरोधों में दोगुने से अधिक प्रदर्शन से प्रदर्शन में दोगुनी वृद्धि हुई, और हम फिर से अपने क्लस्टर की सीमाओं के करीब पहुंचने लगे। PHP के मूल में, उपयोगी अनुकूलन (JIT, प्रीलोडिंग) फिर से होने की उम्मीद है, लेकिन वे केवल PHP 7.4 के लिए योजनाबद्ध हैं, और यह संस्करण एक वर्ष से पहले नहीं जारी किया जाएगा। इसलिए, संक्रमण चाल को अब दोहराया नहीं जा सकता है - आपको एप्लिकेशन कोड को स्वयं अनुकूलित करने की आवश्यकता है।

कट के तहत, मैं आपको बताता हूं कि हम ऐसे कार्यों को कैसे करते हैं, हम कौन से टूल का उपयोग करते हैं, और अनुकूलन, विचारों और दृष्टिकोणों के उदाहरण देते हैं जो हम लागू करते हैं और जिसने हमारे समय में हमारी मदद की।

अनुकूलन क्यों?

प्रदर्शन समस्या को हल करने का सबसे आसान और सबसे स्पष्ट तरीका लोहे को जोड़ना है। यदि आपका कोड एक ही सर्वर पर चलता है, तो एक और जोड़ने से आपके क्लस्टर का प्रदर्शन दोगुना हो जाएगा। डेवलपर की कार्य अवधि के लिए इन लागतों को स्थानांतरित करते हुए, हम खुद से पूछते हैं: क्या वह इस समय के दौरान उत्पादकता में दो गुना वृद्धि प्राप्त कर पाएंगे? शायद हां, लेकिन शायद नहीं: यह इस बात पर निर्भर करता है कि सिस्टम पहले से कितना बेहतर काम कर रहा है और डेवलपर कितना अच्छा है। दूसरी ओर, खरीदा गया सर्वर कंपनी की संपत्ति बना रहेगा, और बिताया गया समय वापस नहीं होगा।

यह पता चला है कि छोटे संस्करणों पर सही समाधान अक्सर लोहे के अतिरिक्त होगा।

लेकिन हमारी स्थिति ले लो। अब, PHP 7.0 में स्विच करने से प्राप्त होने के बाद गतिविधि में वृद्धि और उपयोगकर्ताओं की संख्या से ऑफसेट किया गया था, हमारे पास फिर से 600 सर्वर हैं जो PHP अनुप्रयोग के लिए अनुरोध करते हैं। डेढ़ गुना क्षमता बढ़ाने के लिए, हमें 300 सर्वर जोड़ने होंगे।

एक सर्वर की औसत लागत की गणना के लिए ले लो - $ 4,000। 300 * 4000 = $ 1,200,000 - डेढ़ गुना क्षमता बढ़ाने की लागत।

यही है, हमारी स्थितियों में, हम सिस्टम को अनुकूलित करने में एक महत्वपूर्ण मात्रा में निवेश कर सकते हैं, और यह अभी भी लोहे को खरीदने की तुलना में अधिक लाभदायक होगा।

क्षमता योजना

कुछ भी करने से पहले, यह समझना महत्वपूर्ण है कि क्या कोई समस्या है। यदि वह नहीं है, तो यह भविष्यवाणी करने के लायक है कि वह कब दिखाई दे सकती है। इस प्रक्रिया को क्षमता नियोजन कहा जाता है।

प्रदर्शन समस्याओं की उपस्थिति का एक ठोस संकेतक प्रतिक्रिया समय है। सब के बाद, वास्तव में, इससे कोई फर्क नहीं पड़ता कि सीपीयू (या अन्य संसाधन) 6% या 146% पर लोड किया गया है: यदि एक क्लाइंट को संतोषजनक समय में आवश्यक गुणवत्ता की सेवा मिलती है, तो सब कुछ अच्छी तरह से काम करता है।

प्रतिक्रिया समय पर ध्यान केंद्रित करने का नुकसान यह है कि यह आमतौर पर केवल तब ही बढ़ना शुरू होता है जब समस्या पहले ही प्रकट हो चुकी होती है। यदि यह अभी तक नहीं है, तो इसकी उपस्थिति की भविष्यवाणी करना मुश्किल है। इसके अलावा, प्रतिक्रिया समय सभी कारकों (ब्रेकिंग सेवाओं, नेटवर्क, ड्राइव, आदि) के प्रभाव के परिणामों को दर्शाता है और समस्याओं के कारणों की समझ प्रदान नहीं करता है।

हमारे मामले में, सीपीयू आमतौर पर अड़चन है, इसलिए समूहों के आकार और प्रदर्शन की योजना बनाते समय, हम मुख्य रूप से इसके उपयोग से जुड़े मैट्रिक्स पर ध्यान देते हैं। हम अपनी सभी मशीनों से सीपीयू का उपयोग करते हैं और औसत मूल्य, औसत, 75 वें और 95 वें प्रतिशत के साथ ग्राफ का निर्माण करते हैं:

प्रतिशत में क्लस्टर मशीनों का सीपीयू उपयोग: औसत, औसत, प्रतिशत

हमारे समूहों में सैकड़ों मशीनें हैं जो कई वर्षों से वहां जोड़े गए हैं। वे विन्यास और प्रदर्शन में भिन्न हैं (क्लस्टर सजातीय नहीं है)। हमारे बैलेंसर इसे ( लेख और वीडियो ) को ध्यान में रखते हैं और मशीनों को उनकी क्षमताओं के अनुसार लोड करते हैं। इस प्रक्रिया को नियंत्रित करने के लिए, हमारे पास अधिकतम और न्यूनतम लोडेड मशीनों की एक अनुसूची भी है।

सबसे अधिक और कम से कम भरी हुई क्लस्टर मशीनें

यदि आप इन ग्राफ्स (या सिर्फ शीर्ष कमांड के आउटपुट पर) को देखते हैं और 50% का सीपीयू लोड देखते हैं, तो आपको लगता है कि हमारे पास अभी भी लोड में दो गुना वृद्धि का मार्जिन है। लेकिन वास्तव में आमतौर पर ऐसा नहीं होता है। और यहाँ क्यों है।

हाइपर थ्रेडिंग

हाइपरट्रेडिंग के बिना एक कोर की कल्पना करें। हम इसे एक सीपीयू-बाउंड थ्रेड के साथ लोड करते हैं। हम शीर्ष में 100% लोड होते देखेंगे।

अब इस कर्नेल पर हाइपर्रेडिंग चालू करें और इसे ठीक उसी तरह लोड करें। शीर्ष में, हम पहले से ही दो तार्किक कोर देखेंगे, और कुल भार 50% होगा (आमतौर पर एक 0% पर, और अन्य 100% पर)।

सीपीयू उपयोग: शीर्ष डेटा और वास्तव में क्या होता है

मानो प्रोसेसर केवल 50% लोड है। लेकिन शारीरिक रूप से कोई अतिरिक्त मुक्त कोर दिखाई नहीं दिया। हाइपरट्रेडिंग कुछ मामलों में एक समय में एक से अधिक शारीरिक कोर पर निष्पादित करने की अनुमति देता है । लेकिन यह विशिष्ट परिस्थितियों में प्रदर्शन को दोगुना करने से बहुत दूर है, हालांकि सीपीयू उपयोग ग्राफ पर यह आधे संसाधनों की तरह दिखता है: 50% से 100% तक।

इसका मतलब यह है कि 50% CPU उपयोग के बाद जब हाइपरट्रेडिंग को सक्षम किया जाता है, तो यह उतना ही नहीं बढ़ेगा जितना पहले हुआ था।

मैंने इस कोड को प्रदर्शित करने के लिए लिखा था (यह किसी प्रकार का सिंथेटिक मामला है, वास्तव में परिणाम भिन्न होंगे):

स्क्रिप्ट कोड

<?php $concurrency = $_SERVER['argv'][1] ?? 1; $hashes = 100000000; $chunkSize = intval($hashes / $concurrency); $t1 = microtime(true); $children = array(); for ($i = 0; $i < $concurrency; $i++) {    $pid = pcntl_fork();    if (0 === $pid) {        $first = $i * $chunkSize;        $last = ($i + 1) * $chunkSize - 1;        for ($j = $first; $j < $last; $j++) {            $dummy = md5($j);        }        printf("[%d]: %d hashes in %0.4f sec\n", $i, $last - $first, microtime(true) - $t1);        exit;    } else {        $children[$pid] = 1;    } } while (count($children) > 0) {    $pid = pcntl_waitpid(-1, $status);    if ($pid > 0) {        unset($children[$pid]);    } else {        exit("Got a error pid=$pid");    } }

मेरे लैपटॉप पर दो भौतिक कोर हैं। समानांतर C प्रक्रियाओं की एक अलग संख्या के साथ इसके प्रदर्शन को मापने के लिए इस कोड को विभिन्न इनपुट डेटा के साथ चलाएं।

माप के परिणाम

हम लॉन्च के परिणामों की साजिश करते हैं:

समानांतर प्रक्रियाओं की संख्या के आधार पर स्क्रिप्ट प्रदर्शन

आप किस पर ध्यान दे सकते हैं:

सी = 1 और सी = 2 अनुमानित रूप से एचटी = ऑन और एचटी = ऑफ के लिए समान हैं, जब एक भौतिक कोर जोड़ा जाता है तो प्रदर्शन दोगुना हो जाता है;

C = 3 पर, HT के फायदे ध्यान देने योग्य हो जाते हैं: HT = on के लिए, हम अतिरिक्त प्रदर्शन प्राप्त करने में सक्षम थे, जबकि C = 3 के साथ HT = बंद के लिए यह धीरे-धीरे कम होने लगता है;

C = 4 में हम HT के सभी लाभों को देखते हैं; हम एक अतिरिक्त 30% उत्पादकता को निचोड़ने में सक्षम थे, लेकिन इस समय C = 2 की तुलना में, CPU उपयोग 50% से बढ़कर 100% हो गया।

कुल मिलाकर, सीपीयू लोड के शीर्ष 50% में देखने पर, इस स्क्रिप्ट को निष्पादित करते समय हमें 8,065 महाश / सेकंड मिलते हैं, और 100% - 10,511 म्हास / सेकंड पर। इसका मतलब है कि शीर्ष के लगभग 50% पर, हमें अधिकतम सिस्टम प्रदर्शन के 8.065 / 10.511 ~ 77% मिलते हैं, और वास्तव में हमारे पास लगभग 100% बचे हैं - 77% = 23%, और 50% नहीं, जैसा कि यह प्रतीत हो सकता है।

योजना बनाते समय इस तथ्य पर विचार किया जाना चाहिए।

डेमोस्क्रिप्ट के लिए सीपीयू उपयोग: शीर्ष डेटा और वास्तव में क्या होता है

यातायात की असंगति

हाइपरट्रेडिंग के अलावा, प्लानिंग दिन के समय, सप्ताह के दिन, मौसम और अन्य आवृत्ति के आधार पर यातायात की असमानता को भी जटिल करती है। हमारे लिए, उदाहरण के लिए, चोटी रविवार की शाम है।

प्रति सेकंड अनुरोधों की संख्या, रविवार शाम को चोटी

हमेशा अनुरोधों की संख्या स्पष्ट तरीके से नहीं बदलती है। उदाहरण के लिए, उपयोगकर्ता किसी तरह अन्य उपयोगकर्ताओं के साथ बातचीत कर सकते हैं: कुछ की गतिविधि दूसरों को धक्का / ईमेल उत्पन्न कर सकती है और इस तरह उन्हें इस प्रक्रिया में शामिल कर सकती है। इसमें ट्रैफ़िक बढ़ाने वाले प्रचार अभियान जोड़े जाते हैं और जिसके लिए आपको तैयार रहना भी आवश्यक है।

यह सब योजना बनाते समय विचार करने के लिए भी महत्वपूर्ण है: उदाहरण के लिए, पीक दिनों द्वारा एक प्रवृत्ति का निर्माण करना और चोटी के विकास के संभावित गैर-रैखिकता को ध्यान में रखना।

प्रोफाइलिंग और मापने के उपकरण

मान लें कि हमें पता चलता है कि प्रदर्शन समस्याएं हैं, तो समझें कि यह डेटाबेस / सेवाएं / सामान नहीं है, और फिर भी हमने कोड को अनुकूलित करने का निर्णय लिया। ऐसा करने के लिए, सबसे पहले, हमें बाधाओं को खोजने के लिए एक प्रोफाइलर या कुछ टूल की आवश्यकता होती है और बाद में हमारे अनुकूलन के परिणाम देखें।

दुर्भाग्य से, आज PHP के लिए कोई अच्छा सार्वभौमिक उपकरण नहीं है।

पर्फ़

perf लिनक्स कर्नेल में निर्मित एक प्रोफाइलिंग टूल है। यह एक नमूना प्रोफाइलर है जिसे एक अलग प्रक्रिया द्वारा लॉन्च किया जाता है, इसलिए यह प्रोग्राम को सीधे ओवरहेड किए जाने के लिए एक ओवरहेड नहीं जोड़ता है। अप्रत्यक्ष रूप से जोड़ा गया ओवरहेड समान रूप से "स्मीयर" है, इसलिए यह माप को विकृत नहीं करता है।

अपने सभी फायदों के लिए, perf केवल संकलित कोड के साथ और JIT के साथ काम करने में सक्षम है और "वर्चुअल मशीन के तहत" कोड चलाने के साथ काम करने में सक्षम नहीं है। इसलिए, PHP कोड को इसमें शामिल नहीं किया जा सकता है, लेकिन आप स्पष्ट रूप से देख सकते हैं कि PHP विभिन्न PHP एक्सटेंशन सहित, और अंदर कितने संसाधन खर्च किए जाते हैं।

उदाहरण के लिए, perf के साथ, हमें एक संपीड़न स्थान सहित कई अड़चनें मिलीं, जिनके बारे में मैं नीचे चर्चा करूंगा।

एक उदाहरण:

perf record --call-graph dwarf,65528 -F 99 -p $(pgrep php-cgi | paste -sd "," -) -- sleep 20
perf report

(यदि प्रक्रिया और perf अलग-अलग उपयोगकर्ताओं के तहत निष्पादित किए जाते हैं, तो perf को sudo के तहत चलाने की आवश्यकता होती है)।

PHP-FPM के लिए संपूर्ण रिपोर्ट आउटपुट उदाहरण

XHProf और XHProf एग्रीगेटर

XHProf PHP के लिए एक एक्सटेंशन है जो सभी कॉल को फ़ंक्शन / विधियों के लिए टाइमर के आसपास रखता है, और इस प्रकार प्राप्त परिणामों को विज़ुअलाइज़ करने के लिए उपकरण भी शामिल करता है। Perf के विपरीत, यह आपको PHP-code की शर्तों के साथ काम करने की अनुमति देता है (उसी समय, जो एक्सटेंशन में हो रहा है वह दिखाई नहीं देता है)।

नुकसान में दो चीजें शामिल हैं:

सभी माप एक ही अनुरोध के ढांचे के भीतर एकत्र किए जाते हैं, इसलिए वे चित्र के बारे में पूरी जानकारी नहीं देते हैं;
ओवरहेड, हालांकि उतना बड़ा नहीं है , उदाहरण के लिए, जब Xdebug का उपयोग करते हैं, लेकिन यह है, और कुछ मामलों में परिणाम बहुत विकृत होते हैं (अधिक बार एक फ़ंक्शन को कॉल किया जाता है और यह जितना आसान होता है, उतना ही अधिक विकृति होती है)।

यहाँ एक उदाहरण है जो अंतिम बिंदु को दर्शाता है:

 function child1() { return 1; } function child2() { return 2; } function parent1() { child1(); child2(); return; } for ($i = 0; $i < 1000000; $i++) { parent1(); }

डेमो के लिए XHProf आउटपुट: पेरेंट 1 बच्चे 1 और चाइल्ड 2 के योग से अधिक परिमाण का आदेश है

यह देखा जा सकता है कि parent1 () चाइल्ड 1 () + चाइल्ड 2 () की तुलना में ~ 500 गुना अधिक समय तक निष्पादित किया गया था, हालांकि वास्तव में ये संख्या लगभग बराबर होनी चाहिए, जैसा कि मुख्य () और पेरेंट 1 () के बराबर है।

यदि अंतिम खामी से लड़ना मुश्किल है, तो पहले का मुकाबला करने के लिए हमने एक्सएचप्रोफ के लिए एक ऐड-ऑन बनाया, जो अलग-अलग अनुरोधों के प्रोफाइल को एकत्र करता है और एकत्रित डेटा की कल्पना करता है।

एक्सएचप्रोफ के अलावा, कई अन्य कम-ज्ञात प्रोफाइलर हैं जो एक समान सिद्धांत पर काम कर रहे हैं। उनके समान फायदे और नुकसान हैं।

Pinba

पिनबा आपको स्क्रिप्ट (क्रिया) और पूर्व-निर्धारित समय के अनुसार प्रदर्शन की निगरानी करने की अनुमति देता है। लिपियों के संदर्भ में सभी माप बॉक्स से बाहर किए गए हैं, इसके लिए किसी अतिरिक्त कदम की आवश्यकता नहीं है। प्रत्येक स्क्रिप्ट और टाइमर के लिए, गेट्रेजेज किया जाता है , इसलिए हम ठीक से जानते हैं कि किसी विशेष कोड पर प्रोसेसर का कितना समय बिताया गया था (नमूना प्रोफाइलरों के विपरीत, जहां यह समय नेटवर्क, डिस्क, आदि हो सकता है)। पिनाबा ऐतिहासिक डेटा को बचाने और सामान्य रूप से और विशेष प्रकार के प्रश्नों के भीतर एक तस्वीर प्राप्त करने के लिए बहुत अच्छा है।

पिनबा से प्राप्त सभी लिपियों के सामान्य क्रम

नुकसान में यह तथ्य शामिल है कि कोड के विशिष्ट वर्गों को प्रोफाइल करने वाले टाइमर, और संपूर्ण लिपियों को नहीं, कोड में पहले से व्यवस्थित किया जाना चाहिए, साथ ही एक ओवरहेड की उपस्थिति (जैसे कि XHProf में) डेटा को विकृत कर सकती है।

phpspy

phpspy एक अपेक्षाकृत नई परियोजना है (GitHub पर पहली प्रतिबद्धता एक साल पहले थी), जो आशाजनक लग रही है, इसलिए हम इसे बारीकी से देख रहे हैं।

उपयोगकर्ता के दृष्टिकोण से, phpspy पूर्ण के समान है: एक समानांतर प्रक्रिया शुरू की जाती है, जो समय-समय पर PHP प्रक्रिया के मेमोरी भागों की प्रतिलिपि बनाती है, उन्हें पार्स करती है और वहां से स्टैक के निशान और अन्य डेटा प्राप्त करती है। यह एक विशिष्ट तरीके से किया जाता है। ओवरहेड को कम करने के लिए, phpspy PHP प्रक्रिया को बंद नहीं करता है और इसे चलाने के दौरान सीधे मेमोरी को कॉपी करता है। यह इस तथ्य की ओर जाता है कि प्रोफाइलर एक असंगत स्थिति प्राप्त कर सकता है, स्टैक के निशान को तोड़ा जा सकता है। लेकिन phpspy यह पता लगा सकता है और इस तरह के डेटा को त्याग सकता है।

भविष्य में, इस उपकरण का उपयोग करके चित्र पर दोनों डेटा को एक विशेष प्रकार के प्रश्नों के रूप में एकत्र करना संभव होगा।

तुलना तालिका

उपकरणों के बीच अंतर की संरचना करने के लिए, आइए एक धुरी तालिका बनाते हैं:

प्रोफाइलरों की मुख्य विशेषताओं की तुलना
ज्वाला रेखांकन

अनुकूलन और दृष्टिकोण

इन उपकरणों के साथ, हम अपने संसाधनों के प्रदर्शन और उपयोग की लगातार निगरानी करते हैं। जब उनका उपयोग अनुचित तरीके से किया जाता है या हम थ्रेशोल्ड के पास आ रहे हैं (सीपीयू के लिए हमने आनुभविक रूप से विकास के मामले में कुछ समय के लिए 55% का मान चुना है), जैसा कि मैंने ऊपर लिखा था, समस्या के समाधान में से एक अनुकूलन है।

ठीक है, अगर अनुकूलन पहले से ही किसी और ने किया है, जैसा कि PHP 7.0 के साथ हुआ था, जब यह संस्करण पिछले वाले की तुलना में बहुत अधिक उत्पादक निकला। हम आम तौर पर आधुनिक तकनीकों और उपकरणों का उपयोग करने की कोशिश करते हैं, जिसमें PHP के नवीनतम संस्करणों के लिए समय पर अद्यतन भी शामिल है। सार्वजनिक बेंचमार्क के अनुसार, PHP 7.1 की तुलना में PHP 7.2 5-12% तेज है। लेकिन यह परिवर्तन, अफसोस, हमें बहुत कम दिया।

हर समय हमने बड़ी संख्या में अनुकूलन को लागू किया है। दुर्भाग्य से, उनमें से अधिकांश दृढ़ता से हमारे व्यापारिक तर्क से संबंधित हैं। मैं उन लोगों के बारे में बात करूंगा जो न केवल हमारे लिए, या हमारे कोड के बाहर इस्तेमाल किए जा सकने वाले विचारों और दृष्टिकोणों के लिए प्रासंगिक हो सकते हैं।

ज़ालिब संपीड़न => zstd

हम बड़े मेमेकी कुंजी के लिए संपीड़न का उपयोग करते हैं। यह हमें संपीड़न / अपघटन के लिए अतिरिक्त सीपीयू लागत के कारण भंडारण के लिए तीन से चार गुना कम मेमोरी खर्च करने की अनुमति देता है। हमने इसके लिए zlib का उपयोग किया (मेमके साथ काम करने का हमारा विस्तार PHP के साथ आने वाले लोगों से अलग है, लेकिन आधिकारिक लोग भी zlib का उपयोग करते हैं )।

सही में, उत्पादन कुछ इस तरह था:

+ 4.03% 0.22% php-cgi libz.so.1.2.11 [.] inflate
+ 3.38% 0.00% php-cgi libz.so.1.2.11 [.] deflate

समय का 7-8% संपीड़न / अपघटन पर खर्च किया गया था।

हमने विभिन्न स्तरों और संपीड़न एल्गोरिदम का परीक्षण करने का निर्णय लिया। यह पता चला कि zstd हमारे डेटा पर लगभग दस गुना तेजी से चलता है, ~ 1.1 बार जगह में खो जाता है। एल्गोरिथ्म में एक काफी सरल परिवर्तन ने हमें ~ 7.5% सीपीयू (यह, मुझे याद है, हमारे वॉल्यूम पर ~ 45 सर्वर के बराबर है) बचाया।

यह समझना महत्वपूर्ण है कि विभिन्न संपीड़न एल्गोरिदम के प्रदर्शन का अनुपात इनपुट डेटा के आधार पर बहुत भिन्न हो सकता है। विभिन्न तुलनाएं हैं , लेकिन सबसे सटीक रूप से यह केवल वास्तविक दुनिया के उदाहरणों का उपयोग करके अनुमान लगाया जा सकता है।

IS_ARRAY_IMMUT शायद ही कभी संशोधित डेटा के भंडार के रूप में

वास्तविक कार्यों के साथ काम करते समय, आपको ऐसे डेटा से निपटना पड़ता है जिसकी आपको अक्सर आवश्यकता होती है और एक ही समय में शायद ही कभी परिवर्तन होता है और इसका सीमित आकार होता है। हमारे पास समान डेटा है, एक अच्छा उदाहरण विभाजन परीक्षणों का कॉन्फ़िगरेशन है। हम जांचते हैं कि उपयोगकर्ता किसी विशेष परीक्षा की शर्तों के अंतर्गत आता है या नहीं, और इसके आधार पर हम उसे प्रयोगात्मक या सामान्य कार्यक्षमता दिखाते हैं (यह आपके अनुरोध के दौरान लगभग होता है)। अन्य परियोजनाओं में, कॉन्फ़िगरेशन और विभिन्न निर्देशिकाएं इस तरह का एक उदाहरण हो सकती हैं: देश, शहर, भाषाएं, श्रेणियां, ब्रांड, आदि।

चूंकि इस तरह के डेटा का अक्सर अनुरोध किया जाता है, इसलिए उनकी रसीद आवेदन पर और जिस सेवा में यह डेटा संग्रहीत होता है, दोनों पर ध्यान देने योग्य अतिरिक्त बोझ पैदा कर सकता है। बाद की समस्या को हल किया जा सकता है, उदाहरण के लिए, एपीसीयू का उपयोग करना, जो स्टोरेज के रूप में पीएचपी-एफपीएम चलाने वाली एक ही मशीन की मेमोरी का उपयोग करता है। लेकिन फिर भी:

क्रमांकन / deserialization लागत होगी;
बदलते समय आपको किसी तरह डेटा को अमान्य करना होगा;
PHP में केवल एक चर तक पहुँचने की तुलना में कुछ ओवरहेड है।

PHP 7.0 IS_ARRAY_IMMUTABLE अनुकूलन का परिचय देता है। यदि आप एक सरणी घोषित करते हैं, जिनके सभी तत्व संकलन के समय ज्ञात हैं, तो इसे संसाधित किया जाएगा और एक बार OPCache मेमोरी में रखा जाएगा, PHP-FPM कार्यकर्ता इस साझा मेमोरी को बदलने की कोशिश करने से पहले अपना समय खर्च किए बिना संदर्भित करेंगे। यह इस प्रकार भी है कि इस तरह के एक सरणी को शामिल करने में आकार की परवाह किए बिना निरंतर समय लगेगा (आमतौर पर ~ 1 माइक्रोसेकंड)।

तुलना के लिए: शामिल और apcu_fetch के माध्यम से 10,000 तत्वों की एक सरणी प्राप्त करने के लिए समय का एक उदाहरण:

 $t0 = microtime(true); $a = include 'test-incl-1.php'; $t1 = microtime(true); printf("include (%d): %d microsec\n", count($a), ($t1-$t0) * 1e6); $t0 = microtime(true); $a = apcu_fetch('a'); $t1 = microtime(true); printf("apcu_fetch (%d): %d microsec\n", count($a), ($t1-$t0) * 1e6); //include (10000): 1 microsec //apcu_fetch (10000): 792 microsec

जाँच करें कि क्या यह अनुकूलन लागू किया गया है, यदि आप जनरेट किए गए ऑपकोड को देखें तो यह बहुत सरल हो सकता है:

 $ cat immutable.php <?php return [ 'key1' => 'val1', 'key2' => 'val2', 'key3' => 'val3', ]; $ cat mutable.php <?php return [ 'key1' => \SomeClass::CONST_1, 'key2' => 'val2', 'key3' => 'val3', ]; $ php -d opcache.enable=1 -d opcache.enable_cli=1 -d opcache.opt_debug_level=0x20000 immutable.php $_main: ; (lines=1, args=0, vars=0, tmps=0) ; (after optimizer) ; /home/ubuntu/immutable.php:1-8 L0 (4): RETURN array(...) $ php -d opcache.enable_cli=1 -d opcache.opt_debug_level=0x20000 mutable.php $_main: ; (lines=5, args=0, vars=0, tmps=2) ; (after optimizer) ; /home/ubuntu/mutable.php:1-8 L0 (4): T1 = FETCH_CLASS_CONSTANT string("SomeClass") string("CONST_1") L1 (4): T0 = INIT_ARRAY 3 T1 string("key1") L2 (5): T0 = ADD_ARRAY_ELEMENT string("val2") string("key2") L3 (6): T0 = ADD_ARRAY_ELEMENT string("val3") string("key3") L4 (6): RETURN T0

पहले मामले में, यह देखा जा सकता है कि फ़ाइल में केवल एक ओपकोड है - समाप्त सरणी की वापसी। दूसरे मामले में, इसका तत्व-दर-तत्व गठन प्रत्येक बार होता है जब यह फ़ाइल निष्पादित होती है।

इस प्रकार, संरचनाओं को एक ऐसे रूप में उत्पन्न करना संभव है जिसे रनटाइम में और अधिक परिवर्तन की आवश्यकता नहीं है। उदाहरण के लिए, ऑटोलॉड के लिए प्रत्येक बार "_" और "\" संकेतों द्वारा वर्ग के नामों को अलग करने के बजाय, आप पत्राचार मानचित्र "कक्षा => पथ" को पूर्व-उत्पन्न कर सकते हैं। इस स्थिति में, रूपांतरण फ़ंक्शन एक ही हैश टेबल कॉल में कम हो जाएगा। यदि आप ऑप्टिमाइज़-ऑटोलैडर विकल्प को सक्षम करते हैं तो संगीतकार इस प्रकार का अनुकूलन करता है।

इस तरह के डेटा को अमान्य करने के लिए, आपको विशेष रूप से कुछ भी करने की आवश्यकता नहीं है - PHP खुद को बदलते समय फ़ाइल को फिर से जोड़ देगा, जैसे कि यह एक सामान्य कोड परिनियोजन के साथ होगा। एकमात्र दोष जिसे आपको नहीं भूलना चाहिए: यदि फ़ाइल बहुत बड़ी है, तो इसे बदलने के बाद पहला अनुरोध एक पुनर्मूल्यांकन का कारण होगा, जो एक मूर्त समय ले सकता है।

प्रदर्शन में शामिल / आवश्यकता है

स्थिर सरणी उदाहरण के विपरीत, वर्ग और फ़ंक्शन घोषणाओं के साथ फाइलें संलग्न करना इतना तेज़ नहीं है। OPCache की उपस्थिति के बावजूद, PHP इंजन को उन्हें प्रोसेस मेमोरी में कॉपी करना चाहिए, निर्भरता को पुनरावर्ती रूप से जोड़ना, जो अंत में प्रति फ़ाइल सैकड़ों माइक्रोसेकंड या यहां तक कि मिलीसेकंड ले सकता है।

यदि आप सिम्फनी 4.1 पर एक नई खाली परियोजना बनाते हैं और कार्रवाई में पहली पंक्ति के रूप में get_included_files () डालते हैं, तो आप देख सकते हैं कि 310 फाइलें पहले से ही जुड़ी हुई हैं। एक वास्तविक परियोजना में, यह संख्या प्रति अनुरोध हजारों तक पहुंच सकती है। यह निम्नलिखित बातों पर ध्यान देने योग्य है।

ऑटो-लैडिंग सुविधाओं का अभाव

फंक्शन ऑटोलडिंग आरएफसी है , लेकिन कई वर्षों से कोई विकास नहीं देखा गया है। इसलिए, यदि कम्पोज़र में एक निर्भरता वर्ग के बाहर के कार्यों को परिभाषित करती है और ये फ़ंक्शन उपयोगकर्ता के लिए सुलभ होना चाहिए, तो यह ऑटोलैडर के प्रत्येक आरंभीकरण के लिए इन कार्यों के साथ एक फ़ाइल को जोड़ने के लिए अनिवार्य द्वारा किया जाता है।

उदाहरण के लिए, कंपोज़र.जसन में से एक निर्भरता को दूर करना, जो कई कार्यों की घोषणा करता है और आसानी से कोड की एक सौ लाइनों द्वारा प्रतिस्थापित किया जाता है, हमने सीपीयू का एक-दो प्रतिशत जीता।

ऑटो-लोडर को अधिक बार कहा जाता है जितना यह लग सकता है।

विचार प्रदर्शित करने के लिए, एक कक्षा के साथ ऐसी फ़ाइल बनाएँ:

 <?php class A extends B implements C {   use D;   const AC1 = \E::E1;   const AC2 = \F::F1;   private static $as3 = \G::G1;   private static $as4 = \H::H1;   private $a5 = \I::I1;   private $a6 = \J::J1;   public function __construct(\K $k = null) {}   public static function asf1(\L $l = null) :? LR { return null; }   public static function asf2(\M $m = null) :? MR { return null; }   public function af3(\N $n = null) :? NR { return null; }   public function af4(\P $p = null) :? PR { return null; } }

रजिस्टर ऑटो-लोडर:

 spl_autoload_register(function ($name) {   echo "Including $name...\n";   include "$name.php"; });

और हम इस वर्ग के लिए कई उपयोग के मामले बनाएंगे:

 include 'A.php' Including B... Including D... Including C... \A::AC1 Including A... Including B... Including D... Including C... Including E... new A() Including A... Including B... Including D... Including C... Including E... Including F... Including G... Including H... Including I... Including J...

आप देख सकते हैं कि जब हम सिर्फ किसी तरह वर्ग को जोड़ते हैं, लेकिन इसका उदाहरण नहीं बनाते हैं, तो अभिभावक, इंटरफेस और लक्षण जुड़े होंगे। यह सभी फ़ाइलों के लिए पुनरावर्ती के रूप में जुड़ा हुआ है जो हल करता है।

एक उदाहरण बनाते समय, सभी स्थिरांक और क्षेत्रों का रिज़ॉल्यूशन इसमें जोड़ा जाता है, जो इसके लिए आवश्यक सभी फ़ाइलों के कनेक्शन की ओर जाता है, जो बदले में, नए वर्गों के लक्षण, माता-पिता और इंटरफेस के पुनरावर्ती कनेक्शन का कारण भी होगा।

उदाहरण निर्माण प्रक्रिया और अन्य मामलों के लिए संबंधित कक्षाओं को जोड़ना

इस समस्या का कोई सार्वभौमिक समाधान नहीं है, आपको बस इसे ध्यान में रखने और कक्षाओं के बीच कनेक्शन की निगरानी करने की आवश्यकता है: एक पंक्ति सैकड़ों फाइलों के कनेक्शन को खींच सकती है।

OPCache सेटिंग्स

यदि आप PHP के निर्माता, रसमस लेरडॉर्फ द्वारा प्रस्तावित सिमलिंक को बदलकर परमाणु तैनाती पद्धति का उपयोग करते हैं, तो पुराने संस्करण पर सिम्लिंक को "चिपके" की समस्या को हल करने के लिए आपको opcache.revalidid_path को शामिल करना होगा, उदाहरण के लिए, इस आलेख में OPCache के बारे में लेख में मेल द्वारा अनुवादित ओपेक द्वारा अनुवादित किया गया है। .Ru समूह।

समस्या यह है कि यह विकल्प महत्वपूर्ण रूप से (औसतन, डेढ़ से दो बार) प्रत्येक फ़ाइल के शामिल होने का समय बढ़ाता है। कुल मिलाकर, यह महत्वपूर्ण मात्रा में संसाधनों का उपभोग कर सकता है (हमारे मामले में, इस विकल्प को अक्षम करने से 7-9% का लाभ मिला)।

इसे निष्क्रिय करने के लिए, आपको दो काम करने होंगे:

वेब सर्वर को सिमिलिंक को हल करना;
PHP स्क्रिप्ट के अंदर फ़ाइलों को सहानुभूति रखने वाले रास्तों से जोड़ना बंद करें, या उन्हें रीडलिंक () या रियलपथ () के माध्यम से बाध्य करें।

यदि सभी फाइलें कम्पोज़र ऑटोलैडर के साथ जुड़ी हुई हैं, तो पहले पूरा होने के बाद दूसरे आइटम को स्वचालित रूप से निष्पादित किया जाएगा: omposer __DIR__ निरंतर का उपयोग करता है, जिसे सही ढंग से हल किया जाएगा।

OPCache के पास कुछ और विकल्प हैं जो लचीलेपन के बदले प्रदर्शन को बढ़ावा दे सकते हैं। आप इसके बारे में अधिक लेख में पढ़ सकते हैं जिसका मैंने ऊपर उल्लेख किया है।

इन सभी अनुकूलन के बावजूद, शामिल अभी भी मुक्त नहीं होगा। इससे निपटने के लिए, PHP 7.4 में प्रीलोड जोड़ने की योजना है।

एपीसीयू लॉक

यद्यपि हम यहां डेटाबेस और सेवाओं के बारे में बात नहीं कर रहे हैं, कोड में विभिन्न प्रकार के ताले भी हो सकते हैं, जो स्क्रिप्ट के निष्पादन समय को बढ़ाते हैं।

जैसे-जैसे अनुरोध बढ़ता गया, हमने चरम समय पर प्रतिक्रिया में तीव्र मंदी देखी। कारणों का पता लगाने के बाद, यह पता चला कि यद्यपि एपीसीयू डेटा प्राप्त करने का सबसे तेज़ तरीका है (मेमेचे, रेडिस और अन्य बाहरी भंडारण की तुलना में), यह एक ही कुंजी के लगातार ओवरराइटिंग के साथ धीरे-धीरे काम कर सकता है।

प्रति सेकंड और रनटाइम के अनुरोधों की संख्या: 16 और 17 अक्टूबर को चोटियां

कैश के रूप में एपीसीयू का उपयोग करते समय, यह समस्या इतनी प्रासंगिक नहीं है, क्योंकि कैशिंग में आमतौर पर दुर्लभ लेखन और अक्सर पढ़ने शामिल होते हैं। लेकिन कुछ कार्यों और एल्गोरिदम (उदाहरण के लिए, सर्किट ब्रेकर ( PHP में कार्यान्वयन )) में अक्सर रिकॉर्डिंग शामिल होती है, जो ताले का कारण बनती है।

इस समस्या का कोई सार्वभौमिक समाधान नहीं है, लेकिन सर्किट ब्रेकर के मामले में इसे हल किया जा सकता है, उदाहरण के लिए, इसे PHP के साथ मशीनों पर स्थापित एक अलग सेवा में डालकर।

बैच प्रसंस्करण

यहां तक कि अगर आप ध्यान में नहीं रखते हैं, तो आमतौर पर क्वेरी निष्पादन समय का एक महत्वपूर्ण हिस्सा अभी भी आरंभीकरण पर खर्च किया जाता है: एक रूपरेखा (उदाहरण के लिए, एक डीआई कंटेनर का निर्माण करना और इसकी सभी निर्भरता को शुरू करना, सभी श्रोताओं को निष्पादित करना, सत्र को निष्पादित करना), सत्र, उपयोगकर्ता, और इसी तरह। पर।

यदि आपका बैकएंड किसी चीज के लिए एक आंतरिक एपीआई है, तो कुछ खास ग्राहकों के लिए अनुरोधों को बंडल करके एकल अनुरोध के रूप में भेजा जा सकता है। इस मामले में, कई अनुरोधों के लिए एक बार प्रारंभ किया जाएगा।

, , . - , . .

Badoo , . PHP-FPM, CPU, , , : IO, CPU .

PHP-FPM — , PHP.

(CPU, IO), . , , , , - , . , . , , .

निष्कर्ष

. PHP .

:

;
;
- , : , ;
: (, , );
: ;
, OPCache PHP, , , ;
: (, , PHP 7.2 , );
: , .

?

आपका ध्यान के लिए धन्यवाद!

PHP प्रदर्शन: योजना, प्रोफाइलिंग, अनुकूलन