प्रीलोडिंग (PHP 7.4) और रोडरनर की कोशिश कर रहा है

नमस्कार, हेब्र!

हम अक्सर PHP प्रदर्शन के बारे में लिखते हैं और बात करते हैं: हम सामान्य रूप से इसके साथ कैसे व्यवहार करते हैं , कैसे हमने PHP 7.0 पर स्विच करते समय $ 1 मिलियन बचाए , और इस विषय पर विभिन्न सामग्रियों का अनुवाद भी किया। यह इस तथ्य के कारण है कि हमारे उत्पादों के दर्शक बढ़ रहे हैं, और लोहे के साथ PHP बैकेंड का स्केलिंग बहुत महंगा है - हमारे पास PHP-FPM के साथ 600 सर्वर हैं। इसलिए, अनुकूलन में समय का निवेश हमारे लिए फायदेमंद है।

इससे पहले, हमने मुख्य रूप से उत्पादकता के साथ काम करने के सामान्य और पहले से स्थापित तरीकों के बारे में बात की। लेकिन PHP समुदाय अलर्ट पर है! JIT PHP 8 में दिखाई देगा, PHP 7.4 में प्रीलोड दिखाई देगा, और PHP के विकास के मूल के बाहर चौखटे विकसित किए जाएंगे, जो यह मानते हैं कि PHP एक डेमन के रूप में काम करता है। यह कुछ नया प्रयोग करने का समय है और देखें कि यह हमें क्या दे सकता है।

चूंकि PHP 8 की रिहाई अभी भी एक लंबा रास्ता तय कर रही है, और अतुल्यकालिक रूपरेखाएं हमारे कार्यों के लिए खराब रूप से अनुकूल हैं (क्यों - मैं नीचे बताऊंगा), आज हम प्रीलोड पर ध्यान केंद्रित करेंगे, जो PHP 7.4 में दिखाई देगा, और PHP, RoadRunner के लिए रूपरेखा।

यह मेरी रिपोर्ट का पाठ संस्करण है, जिसमें PHP PHP Meetup # 3 है । इस पोस्ट में हमारे द्वारा एकत्र किए गए सभी भाषणों का वीडियो।

PHP-FPM, Apache mod_php, और PHP स्क्रिप्ट और प्रक्रिया अनुरोधों को चलाने के लिए इसी तरह के तरीके (जो कि अधिकांश साइटों और सेवाओं द्वारा चलाए जाते हैं; सादगी के लिए, मैं उन्हें "क्लासिक" PHP कहूँगा) शब्द के व्यापक अर्थों में साझा-कुछ के आधार पर काम करते हैं:

• PHP श्रमिकों के बीच राज्य को अफवाह नहीं है;
  
• राज्य विभिन्न अनुरोधों के बीच रम्मा नहीं है।
  

एक साधारण स्क्रिप्ट के उदाहरण के साथ इस पर विचार करें:

//  $app = \App::init(); $storage = $app->getCitiesStorage(); //   $name = $storage->getById($_COOKIE['city_id']); echo " : {$name}"; 

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

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

 //  $app = \App::init(); $storage = $app->getCitiesStorage(); $cities = $storage->getAll(); //    while ($req = getNextRequest()) {    $name = $cities[$req->getCookie('city_id')];    echo " : {$name}"; } 

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

इस तरह के समाधान का प्रदर्शन संभावित रूप से "क्लासिक" पीएचपी की तुलना में काफी अधिक है। लेकिन आमतौर पर उत्पादकता में वृद्धि मुफ्त में नहीं दी जाती है - आपको इसके लिए कुछ कीमत चुकानी होगी। आइए देखें कि यह हमारे मामले में क्या हो सकता है।

ऐसा करने के लिए, आइए हमारी स्क्रिप्ट को थोड़ा जटिल करें और $name चर प्रदर्शित करने के बजाय, हम सरणी को पॉप्युलेट करेंगे:

 -  $name = $cities[$req->getCookie('city_id')]; +  $names[] = $cities[$req->getCookie('city_id')]; 

"क्लासिक" PHP के मामले में, कोई समस्या उत्पन्न नहीं होगी - क्वेरी के अंत में, $name चर नष्ट हो जाएगा और प्रत्येक बाद का अनुरोध अपेक्षा के अनुरूप काम करेगा। PHP को डेमॉन के रूप में शुरू करने के मामले में, प्रत्येक अनुरोध इस चर में एक और शहर जोड़ देगा, जिससे मेमोरी पर मशीन के बाहर निकलने तक सरणी का अनियंत्रित विकास होगा।

सामान्य तौर पर, न केवल स्मृति समाप्त हो सकती है - कुछ अन्य त्रुटियां हो सकती हैं जो प्रक्रिया की मृत्यु का कारण बनेंगी। ऐसी समस्याओं के साथ, "क्लासिक" PHP स्वचालित रूप से संभालती है। PHP को डेमॉन के रूप में शुरू करने के मामले में, हमें किसी तरह इस डेमॉन की निगरानी करने की आवश्यकता है, अगर यह क्रैश हो जाता है तो इसे पुनः आरंभ करें।

इस प्रकार की त्रुटियां अप्रिय हैं, लेकिन उनके लिए प्रभावी समाधान हैं। यह बहुत बुरा है अगर, एक त्रुटि के कारण, स्क्रिप्ट नहीं गिरती है, लेकिन अप्रत्याशित रूप से कुछ चर के मूल्यों को बदल देता है (उदाहरण के लिए, यह $cities सरणी को साफ करता है)। इस मामले में, बाद के सभी अनुरोध गलत डेटा के साथ काम करेंगे।

संक्षेप में, "क्लासिक" PHP (PHP-FPM, Apache mod_php और इस तरह) के लिए कोड लिखना आसान है - यह हमें कई समस्याओं और त्रुटियों से मुक्त करता है। लेकिन इसके लिए हम प्रदर्शन के साथ भुगतान करते हैं।

उपरोक्त उदाहरणों से, हम देखते हैं कि कोड के कुछ हिस्सों में, PHP उन संसाधनों को खर्च करता है जो "क्लासिक" एक के प्रत्येक अनुरोध को संसाधित करने में खर्च नहीं किए जा सकते थे (या एक बार बर्बाद हो गए थे)। ये निम्नलिखित क्षेत्र हैं:

• फ़ाइल कनेक्शन (शामिल करें, आवश्यकता, आदि);
  
• आरंभीकरण (ढांचा, पुस्तकालय, डीआई कंटेनर, आदि);
  
• बाह्य संग्रहण (स्मृति में भंडारण के बजाय) से डेटा का अनुरोध करें।
  

PHP कई सालों से है और काम के इस मॉडल की बदौलत लोकप्रिय भी हो सकती है। इस समय के दौरान, वर्णित समस्या को हल करने के लिए सफलता की बदलती डिग्री के कई तरीके विकसित किए गए थे। मैंने उनमें से कुछ का उल्लेख अपने पिछले लेख में किया था । आज हम समुदाय के लिए दो नए समाधानों पर ध्यान केंद्रित करेंगे: प्रीलोड और रोडरनर।

प्रीलोड

ऊपर सूचीबद्ध तीन बिंदुओं में से, प्रीलोड को फाइल कनेक्ट करते समय पहले ओवरहेड से निपटने के लिए डिज़ाइन किया गया है। पहली नज़र में, यह अजीब और अर्थहीन लग सकता है, क्योंकि PHP में पहले से ही OPcache है, जो सिर्फ इस उद्देश्य के लिए बनाया गया था। सार को समझने के लिए, आइए परफ़ैक्ट की मदद से वास्तविक प्रोफ़ाइल करें, जिस पर ओपचे सक्षम है, हिट दर 100% के बराबर है।



OPcache के बावजूद, हम देखते हैं कि persistent_compile_file क्वेरी निष्पादन समय का 5.84% लेता है।

ऐसा क्यों होता है यह समझने के लिए, हम zend_accel_load_script के स्रोतों को देख सकते हैं । यह उन लोगों से देखा जा सकता है, include/require लिए प्रत्येक कॉल के साथ ओपचे की उपस्थिति के बावजूद include/require कक्षाओं और कार्यों include/require हस्ताक्षर साझा मेमोरी से कार्यकर्ता प्रक्रिया की मेमोरी में कॉपी किए जाते हैं, और विभिन्न सहायक कार्य किए जाते हैं। और यह काम प्रत्येक अनुरोध के लिए किया जाना चाहिए, क्योंकि इसके अंत में कार्यकर्ता प्रक्रिया की स्मृति को साफ कर दिया जाता है।



इसमें बड़ी संख्या में शामिल / कॉल की आवश्यकता होती है जिसे हम आमतौर पर एक अनुरोध में बनाते हैं। उदाहरण के लिए, सिम्फनी 4 में कोड की पहली उपयोगी लाइन निष्पादित करने से पहले लगभग 310 फाइलें शामिल हैं। कभी-कभी यह अंतर्निहित रूप से होता है: कक्षा ए का एक उदाहरण बनाने के लिए, नीचे दिखाया गया है, पीएचपी अन्य सभी वर्गों (बी, सी, डी, ई, एफ, जी) को ऑटोलॉड करेगा। और विशेष रूप से इस संबंध में, कार्य की घोषणा करने वाले संगीतकार की निर्भरताएं बाहर हैं: यह सुनिश्चित करने के लिए कि ये फ़ंक्शन उपयोगकर्ता कोड के निष्पादन के दौरान उपलब्ध होंगे, संगीतकार को हमेशा उपयोग की परवाह किए बिना उन्हें कनेक्ट करना होगा, क्योंकि PHP में ऑटोलॉड फ़ंक्शन नहीं हैं और वे नहीं हो सकते हैं कॉल के समय लोड किया गया।

 class A extends \B implements \C {    use \D;    const SOME_CONST = \E::E1;    private static $someVar = \F::F1;    private $anotherVar = \G::G1; } 

प्रीलोड कैसे काम करता है

प्रीलोड में एक एकल मुख्य सेटिंग है, opcache.preload, जिसमें PHP स्क्रिप्ट के लिए मार्ग पारित किया गया है। PHP-FPM / Apache / इत्यादि को शुरू करते समय इस स्क्रिप्ट को निष्पादित किया जाएगा, और इस फ़ाइल में घोषित की जाने वाली कक्षाओं, विधियों और कार्यों के सभी हस्ताक्षर सभी स्क्रिप्ट के लिए उपलब्ध होंगे जो उनके निष्पादन की पहली पंक्ति से प्रक्रिया का अनुरोध करते हैं (महत्वपूर्ण) ध्यान दें: यह चर और वैश्विक स्थिरांक पर लागू नहीं होता है - प्रीलोड चरण के अंत के बाद उनके मान शून्य पर रीसेट हो जाएंगे)। आपको साझा मेमोरी से प्रोसेस मेमोरी में कॉल / कॉपी फंक्शन / क्लास सिग्नेचर को शामिल करने / उसकी आवश्यकता बनाने की आवश्यकता नहीं है: उन्हें सभी अपरिवर्तनीय घोषित किया जाता है और इस कारण सभी प्रक्रियाएं उसी मेमोरी लोकेशन को संदर्भित कर सकती हैं।

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

बेंचमार्क प्रीलोड

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

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

प्रीलोड करने का प्रयास करने के लिए, आपको पहले PHP 7.4 (अब हमारे पास PHP 7.2 है) में अपग्रेड करना होगा। मैंने प्रीलोड के साथ PHP 7.2, PHP 7.4 के बिना PHP और PHP 7.4 के प्रदर्शन को मापा। परिणाम एक ऐसी तस्वीर है:



इस प्रकार, PHP 7.2 से PHP 7.4 तक का संक्रमण हमारे समापन बिंदु पर प्रदर्शन करने के लिए + 10% देता है, और प्रीलोड ऊपर से एक और 10% देता है।

प्रीलोड के मामले में, परिणाम बहुत हद तक कनेक्टेड फ़ाइलों की संख्या और निष्पादन योग्य लॉजिक की जटिलता पर निर्भर करेगा: यदि कई फाइलें कनेक्टेड हैं और लॉजिक सरल है, तो प्रीलोड्स कुछ फाइलें होने पर अधिक तर्क देंगे और लॉजिक जटिल है।

प्रीलोड की बारीकियां

क्या उत्पादकता बढ़ जाती है आमतौर पर एक नकारात्मक पहलू है। प्रीलोड में बहुत सारी बारीकियां हैं, जो मैं नीचे दूंगा। उन सभी को ध्यान में रखा जाना चाहिए, लेकिन केवल एक (पहले) मौलिक हो सकता है।

बदलाव - पुनः आरंभ

चूंकि सभी प्रीलोड फाइलें केवल स्टार्टअप पर संकलित की जाती हैं, जिन्हें अपरिवर्तनीय के रूप में चिह्नित किया जाता है और भविष्य में इसे पुन: कंपाइल नहीं किया जाता है, इन फाइलों में परिवर्तन लागू करने का एकमात्र तरीका PHP- FPM / Apache /, आदि को पुनः आरंभ (पुनः लोड या पुनः आरंभ) करना है।

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

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

अपरिभाषित पात्र

किसी कक्षा को लोड करने के लिए पहले से लोड करने के लिए, इस पर निर्भर सब कुछ इस बिंदु तक परिभाषित किया जाना चाहिए। नीचे दिए गए वर्ग के लिए, इसका मतलब है कि अन्य सभी कक्षाएं (बी, सी, डी, ई, एफ, जी), $someGlobalVar चर, और SOME_CONST निरंतर इस वर्ग को संकलित करने से पहले उपलब्ध होना चाहिए। चूंकि प्रीलोड स्क्रिप्ट सिर्फ नियमित PHP कोड है, इसलिए हम एक ऑटोलैडर को परिभाषित कर सकते हैं। इस मामले में, अन्य वर्गों से जुड़ी हर चीज अपने आप लोड हो जाएगी। लेकिन यह चर और स्थिरांक के साथ काम नहीं करता है: हमें स्वयं यह सुनिश्चित करना चाहिए कि जिस समय यह वर्ग घोषित किया गया है उस समय उन्हें परिभाषित किया गया हो।

 class A extends \B implements \C {    use \D;    const SOME_CONST = \E::E1;    private static $someVar = \F::F1;    private $anotherVar = \G::G1;    private $varLink = $someGlobalVar;    private $constLink = SOME_CONST; } 

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

 PHP Warning: Can't preload class MyTestClass with unresolved initializer for constant RAND in /local/preload-internal.php on line 6 PHP Warning: Can't preload unlinked class MyTestClass: Unknown parent AnotherClass in /local/preload-internal.php on line 5 

दूसरे, प्रीलोड opcache_get_status () फ़ंक्शन के परिणाम में एक अलग अनुभाग जोड़ता है, जो दिखाता है कि प्रीलोड चरण में सफलतापूर्वक क्या लोड किया गया था:

कक्षा क्षेत्र / निरंतर अनुकूलन

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

 const.php: <?php define('MYTESTCONST', mt_rand(1, 1000)); 

 preload.php: <?php include 'const.php'; class MyTestClass {    const RAND = MYTESTCONST; } 

 script.php: <?php include 'const.php'; echo MYTESTCONST, ', ', MyTestClass::RAND; // 32, 154 

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

कुछ पुनः लोड नहीं किया जा सकता है ()

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

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

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

PHP 7.4 आधिकारिक तौर पर अभी तक (अभी तक) जारी नहीं किया गया है

कुछ समय बाद यह बारीकियां अप्रासंगिक हो जाएंगी, लेकिन अभी तक PHP 7.4 के संस्करण को आधिकारिक तौर पर जारी नहीं किया गया है और रिलीज़ नोटों में PHP टीम स्पष्ट रूप से लिखती है : "कृपया उत्पादन में इस संस्करण का उपयोग न करें, यह एक प्रारंभिक परीक्षण संस्करण है।" प्रीलोड के साथ हमारे प्रयोगों के दौरान, हम कई बग्स में आए, हमने उन्हें खुद को ठीक किया और यहां तक ​​कि कुछ को ऊपर की तरफ भेजा । आश्चर्य से बचने के लिए, आधिकारिक रिलीज की प्रतीक्षा करना बेहतर है।

RoadRunner

रोडरनर गो में लिखा एक डेमॉन है, जो एक ओर, PHP कार्यकर्ता बनाता है और उन्हें मॉनिटर करता है (आवश्यक के रूप में शुरू / समाप्त / पुनरारंभ होता है), और दूसरी ओर, इन श्रमिकों को अनुरोध स्वीकार करता है और उन्हें पारित करता है। इस अर्थ में, इसका काम PHP-FPM (जहाँ एक मास्टर प्रक्रिया भी है जो श्रमिकों पर नज़र रखता है) के काम से अलग नहीं है। लेकिन अभी भी मतभेद हैं। कुंजी यह है कि क्वेरी पूरा होने के बाद रोडरनर स्क्रिप्ट की स्थिति को रीसेट नहीं करता है।

इस प्रकार, अगर हम अपनी सूची को याद करते हैं कि "क्लासिक" PHP के मामले में कौन से संसाधन खर्च किए जाते हैं, तो रोडरनर आपको सभी बिंदुओं से निपटने की अनुमति देता है (प्रीलोड, जैसा कि हम याद करते हैं, केवल पहले के साथ है):

• फ़ाइल कनेक्शन (शामिल करें, आवश्यकता, आदि);
  
• आरंभीकरण (ढांचा, पुस्तकालय, डीआई कंटेनर, आदि);
  
• बाह्य संग्रहण (स्मृति में भंडारण के बजाय) से डेटा का अनुरोध करें।
  

हैलो वर्ल्ड रोडरनर उदाहरण कुछ इस तरह दिखता है:

 $relay = new Spiral\Goridge\StreamRelay(STDIN, STDOUT); $psr7 = new Spiral\RoadRunner\PSR7Client(new Spiral\RoadRunner\Worker($relay)); while ($req = $psr7->acceptRequest()) {        $resp = new \Zend\Diactoros\Response();        $resp->getBody()->write("hello world");        $psr7->respond($resp); } 

हम अपने वर्तमान समापन बिंदु की कोशिश करेंगे, जिसे हमने प्रीलोड के साथ परीक्षण किया था, रोडरनर पर संशोधनों के बिना चलाने के लिए, इसे लोड करें और प्रदर्शन को मापें। कोई संशोधन नहीं - क्योंकि अन्यथा बेंचमार्क पूरी तरह से ईमानदार नहीं होगा।

आइए इसके लिए हैलो वर्ल्ड उदाहरण को अनुकूलित करने का प्रयास करें।

सबसे पहले, जैसा कि मैंने ऊपर लिखा है, हम नहीं चाहते हैं कि कार्यकर्ता त्रुटि की स्थिति में गिर जाए। ऐसा करने के लिए, हमें एक वैश्विक प्रयास में सब कुछ लपेटने की आवश्यकता है..चेक करें। दूसरे, चूँकि हमारी स्क्रिप्ट को Zend Diactoros के बारे में कुछ भी नहीं पता है, जवाब के लिए हमें इसके परिणामों को बदलने की आवश्यकता होगी। इसके लिए हम ob_-functions का उपयोग करते हैं। तीसरा, हमारी लिपि को PSR-7 अनुरोध की प्रकृति के बारे में कुछ भी पता नहीं है। समाधान इन संस्थाओं से मानक PHP वातावरण को आबाद करने के लिए है। और चौथा, हमारी लिपि को उम्मीद है कि मरने का अनुरोध किया जाएगा और पूरे राज्य को साफ कर दिया जाएगा। इसलिए, रोडरनर के साथ हमें यह सफाई खुद करने की आवश्यकता होगी।

इस प्रकार, प्रारंभिक हैलो वर्ल्ड संस्करण कुछ इस तरह से बदल जाता है:

 while ($req = $psr7->acceptRequest()) {    try {        $uri = $req->getUri();        $_COOKIE = $req->getCookieParams();        $_POST = $req->getParsedBody();        $_SERVER = [            'REQUEST_METHOD' => $req->getMethod(),            'HTTP_HOST' => $uri->getHost(),            'DOCUMENT_URI' => $uri->getPath(),            'SERVER_NAME' => $uri->getHost(),            'QUERY_STRING' => $uri->getQuery(),            // ...        ];        ob_start();        // our logic here        $output = ob_get_contents();        ob_clean();               $resp = new \Zend\Diactoros\Response();        $resp->getBody()->write($output, 200);        $psr7->respond($resp);    } catch (\Throwable $Throwable) {        // some error handling logic here    }    \UDS\Event::flush();    \PinbaClient::sendAll();    \PinbaClient::flushAll();    \HTTP::clear();    \ViewFactory::clear();    \Logger::clearCaches();       // ... } 

बेंचमार्क रोडरनर

वैसे, बेंचमार्क लॉन्च करने का समय आ गया है।



परिणाम अपेक्षाओं पर खरे नहीं उतरते: रोडरनर आपको प्रीलोड की तुलना में प्रदर्शन के नुकसान के कारण अधिक कारकों को समतल करने की अनुमति देता है, लेकिन परिणाम बदतर हैं। आइए जानें कि ऐसा क्यों होता है, हमेशा की तरह, इसके लिए पूर्णता दौड़ने से।



सही परिणामों में, हमें phar_compile_file दिखाई देता है। ऐसा इसलिए है क्योंकि हम स्क्रिप्ट के निष्पादन के दौरान कुछ फ़ाइलों को शामिल करते हैं, और चूंकि OPcache सक्षम नहीं है (RoadRunner CLI के रूप में स्क्रिप्ट चलाता है, जहां OPcache डिफ़ॉल्ट रूप से बंद हो जाता है), इन फ़ाइलों को प्रत्येक अनुरोध के साथ फिर से संकलित किया जाता है।

रोडरनर कॉन्फ़िगरेशन संपादित करें - OPcache सक्षम करें:





ये परिणाम पहले से ही अधिक हैं जैसे कि हम क्या देखने की उम्मीद करते हैं: रोडरनर ने प्रीलोड की तुलना में अधिक प्रदर्शन दिखाना शुरू कर दिया। लेकिन शायद हम और भी अधिक प्राप्त करने में सक्षम होंगे!

लगता है कि perf के साथ कुछ भी अधिक असामान्य नहीं है - आइए PHP कोड को देखें। प्रोफ़ाइल करने का सबसे आसान तरीका यह है कि आप phpspy का उपयोग करें : इसे PHP कोड के किसी भी संशोधन की आवश्यकता नहीं है - आपको इसे कंसोल में चलाने की आवश्यकता है। आइए इसे करें और एक लौ ग्राफ बनाएं:



चूंकि हम प्रयोग की शुद्धता के लिए हमारे आवेदन के तर्क को संशोधित नहीं करने पर सहमत हुए, इसलिए हम रोडरनर के काम से जुड़ी स्टैक शाखा में रुचि रखते हैं:



इसका मुख्य भाग फ़्रेड () को कॉल करने के लिए नीचे आता है, इसके साथ शायद ही कुछ किया जा सकता है। लेकिन हम कुछ अन्य शाखाओं को \ Spiral \ RoadRunner \ PSR7Client :: acceptRequest () में देखते हैं , केवल खुद को छोड़कर। आप स्रोत कोड को देखकर उनका अर्थ समझ सकते हैं:

    /**     * @return ServerRequestInterface|null     */    public function acceptRequest()    {        $rawRequest = $this->httpClient->acceptRequest();        if ($rawRequest === null) {            return null;        }        $_SERVER = $this->configureServer($rawRequest['ctx']);        $request = $this->requestFactory->createServerRequest(            $rawRequest['ctx']['method'],            $rawRequest['ctx']['uri'],            $_SERVER        );        parse_str($rawRequest['ctx']['rawQuery'], $query);        $request = $request            ->withProtocolVersion(static::fetchProtocolVersion($rawRequest['ctx']['protocol']))            ->withCookieParams($rawRequest['ctx']['cookies'])            ->withQueryParams($query)            ->withUploadedFiles($this->wrapUploads($rawRequest['ctx']['uploads'])); 

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



परीक्षण स्क्रिप्ट काफी आसान थी, इसलिए मैं शुद्ध PHP की तुलना में प्रदर्शन का एक महत्वपूर्ण हिस्सा - + 17% निचोड़ने में कामयाब रहा (मुझे याद है कि प्रीलोड उसी स्क्रिप्ट पर + 10% देता है)।

रोडरनर की बारीकियां

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

-, RoadRunner, , PHP- , , , : , , .

-, RoadRunner , «» — . / RoadRunner ; , , , , - .

-, endpoint', , , RoadRunner. .

निष्कर्ष

, «» PHP, , preload RoadRunner.

PHP «» (PHP-FPM, Apache mod_php ) . - , . , , preload JIT.

, , , RoadRunner, .

, (: ):

• PHP 7.2 — 845 RPS;
  
• PHP 7.4 — 931 RPS;
  
• RoadRunner — 987 RPS;
  
• PHP 7.4 + preload — 1030 RPS;
  
• RoadRunner — 1089 RPS.
  

Badoo PHP 7.4 , ( ).

RoadRunner , , , , .

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