रोडरनर का उपयोग करते हुए हाइब्रिड PHP / गो एप्लीकेशन डेवलपमेंट

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

संकरण के लिए धन्यवाद, पहले से धीमी गति से किए गए एप्लिकेशन ने लोड के तहत 502 त्रुटियों से पीड़ित को रोक दिया, अनुरोधों के औसत प्रतिक्रिया समय में कमी आई, उत्पादकता में वृद्धि हुई, और आवेदन के एकीकरण के कारण और असेंबलिंग आसान हो गई और nxx + php-fpm के रूप में अनावश्यक बाइंडिंग से छुटकारा मिल गया।


एंटोन टिटोव ( Lachezis ) PHP में 12 साल के सक्रिय व्यावसायिक विकास के अनुभव के साथ CTO और SpiralScout LLC के सह-संस्थापक हैं। पिछले कुछ वर्षों में, वह सक्रिय रूप से कंपनी के विकास के ढेर पर गोलंग को लागू कर रहा है। एंटोन ने पीएचपी रूस 2019 में एक उदाहरण के बारे में बात की।

PHP अनुप्रयोग जीवन चक्र

योजनाबद्ध रूप से, एक निश्चित ढांचे के साथ एक सार अनुप्रयोग डिवाइस इस तरह दिखता है।



जब हम किसी प्रक्रिया के लिए अनुरोध भेजते हैं, तो ऐसा होता है:

• परियोजना आरंभीकरण;
• साझा लाइब्रेरी, फ्रेमवर्क और ORM लोड करना;
• एक विशेष परियोजना के लिए आवश्यक लोडिंग लाइब्रेरी;
• मार्ग;
• एक विशिष्ट नियंत्रक के लिए मार्ग अनुरोध;
• प्रतिक्रिया पीढ़ी।

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

आलसी लोडिंग

तेज करने का मानक और आसान तरीका है लेज़ी-लोडिंग सिस्टम या ऑन-डिमांड-लोडिंग लाइब्रेरी का कार्यान्वयन।

आलसी-लोडिंग के साथ हम केवल आवश्यक कोड का अनुरोध करते हैं।

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

कैश लगातार गणना

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



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

प्रसंस्करण का अनुरोध करें

जब बाहरी PHP-FPM सर्वर से अनुरोध प्राप्त होता है, तो अनुरोध प्रविष्टि बिंदु और आरंभीकरण मेल खाएगा।

यह पता चलता है कि ग्राहक का अनुरोध हमारी प्रक्रिया की स्थिति है।

इस राज्य को बदलने का एकमात्र तरीका कार्यकर्ता को पूरी तरह से नष्ट करना और एक नए अनुरोध के साथ शुरू करना है।



यह अपने फायदे के साथ एक सिंगल-थ्रेडेड क्लासिक मॉडल है।

• अनुरोध के अंत में सभी श्रमिकों की मृत्यु हो जाती है।
• PHP में मेमोरी लीक, दौड़ की स्थिति, गतिरोध अंतर्निहित नहीं हैं। आप इसकी चिंता नहीं कर सकते।
• कोड सरल है: हम लिखते हैं, अनुरोध को संसाधित करते हैं, मर जाते हैं और आगे बढ़ते हैं।

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

यह सर्वर पर कैसे काम करता है

सबसे अधिक संभावना है, नगीनक्स और पीएचपी का एक गुच्छा काम करेगा। निग्नेक्स एक रिवर्स प्रॉक्सी के रूप में काम करेगा: उपयोगकर्ताओं को स्टैटिक्स का हिस्सा देगा, और नीचे दिए गए PHP प्रक्रिया प्रबंधक PHP-FPM के अनुरोधों का प्रतिनिधि हिस्सा देगा। पहले से ही प्रबंधक अनुरोध के लिए एक अलग कार्यकर्ता उठाता है और इसे संसाधित करता है। उसके बाद, कार्यकर्ता नष्ट हो जाता है या साफ हो जाता है। अगला, अगले अनुरोध के लिए एक नया कार्यकर्ता बनाया जाता है।



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

आवेदन में तेजी

कैश और लेज़ी-लोडिंग शुरू करने के बाद क्लासिक एप्लिकेशन को कैसे गति दें? अन्य विकल्प क्या हैं?

भाषा की ओर ही मुड़ें ।

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

विकल्पों का उपयोग करें । उदाहरण के लिए, फेसबुक से HHVM वर्चुअल मशीन। यह एक अधिक अनुकूलित वातावरण में कोड निष्पादित करता है। दुर्भाग्य से, HHVM PHP सिंटैक्स के साथ पूरी तरह से संगत नहीं है। एक विकल्प के रूप में, VK या PeachPie से kPHP कंपाइलर, जो कोड को पूरी तरह से .NET C # में परिवर्तित करता है, एक विकल्प है।

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

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

इसे प्राप्त करने के लिए, हम प्रवेश बिंदु को आगे बढ़ाते हैं, जो अनुप्रयोग में गहराई से प्रारंभिक बिंदु के साथ होता था।

प्रवेश बिंदु स्थानांतरित करना - प्रदर्शन

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

हम एप्लिकेशन को अनुकूलित करते हैं

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



मैं एक कार्यकर्ता को डाउनलोड करते समय टेम्पलेट्स को संकलित करने की सलाह नहीं देता, लेकिन डाउनलोड करना, उदाहरण के लिए, सभी कॉन्फ़िगरेशन उपयोगी है।

मॉडल की तुलना करें

प्रदर्शन (बाएं) और क्लासिक मॉडल की तुलना करें।



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

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

लंबे समय तक रहने वाले मॉडल की समस्याएं

फायदे के बावजूद, मॉडल में सीमाओं का एक सेट है।

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

समस्या को दो तरह से हल किया जाता है।

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

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

समस्या को एप्लिकेशन आर्किटेक्चर स्तर पर हल किया जाता है।

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

संसाधन प्रबंधन ।

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

लंबे समय तक रहने वाले मॉडल का अन्वेषण करें

एक लंबे समय तक रहने वाले कार्यकर्ता मॉडल पर विचार करें - एक आवेदन को प्रदर्शित करना - और इसे लागू करने के तरीके का पता लगाना।

गैर-अवरुद्ध दृष्टिकोण

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



दृष्टिकोण का निर्विवाद लाभ अधिकतम प्रदर्शन है। दिलचस्प साधनों का उपयोग करना भी संभव है, उदाहरण के लिए, अपने आवेदन पर सीधे WebSocket को कॉन्फ़िगर करें ।

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

एक गैर-अवरोधक दृष्टिकोण के साथ प्रदर्शन के मामले में समस्याओं को हल करने के लिए, आप अच्छी तरह से ज्ञात उपकरणों का उपयोग कर सकते हैं: ReactPHP , amphp और Swoole - सी-एक्सटेंशन के रूप में एक दिलचस्प विकास। ये उपकरण जल्दी से काम करते हैं, उनके पास एक अच्छा समुदाय और अच्छा दस्तावेज है।

ब्लॉकिंग अप्रोच

हम एप्लिकेशन के अंदर कॉरआउट्स नहीं बढ़ाते हैं, लेकिन इसे बाहर से करते हैं।



जैसा कि PHP-FPM करेगा, हम बस कुछ ही आवेदन प्रक्रियाएँ करते हैं। इन अनुरोधों को एक प्रक्रिया राज्य के रूप में प्रसारित करने के बजाय, हम उन्हें प्रोटोकॉल या संदेश के रूप में बाहर से वितरित करते हैं।

हम वही सिंगल-थ्रेडेड कोड लिखते हैं जिसे हम जानते हैं, हम सभी एक ही लाइब्रेरी और एक ही पीडीओ का उपयोग करते हैं। PHP एप्लिकेशन के बाहर सॉकेट्स, एचटीटीपी और अन्य टूल्स के साथ काम करने की सारी मेहनत की जाती है।

Minuses की: हमें स्मृति की निगरानी करनी चाहिए और याद रखना चाहिए कि दो अलग-अलग प्रक्रियाओं के बीच संचार मुफ्त नहीं है , लेकिन हमें डेटा स्थानांतरित करने की आवश्यकता है। यह एक मामूली ओवरहेड बनाएगा।

समस्या को हल करने के लिए, पहले से ही एक PHP-RM टूल है जो PHP में लिखा गया है। ReactPHP लाइब्रेरी पर, इसका कई फ्रेमवर्क के साथ एकीकरण है । हालाँकि, PHP-PM बहुत धीमा है, यह सर्वर स्तर पर मेमोरी को लीक करता है और लोड के तहत यह PHP-FRM जितना विकास नहीं दिखाता है।

हम अपना एप्लिकेशन सर्वर लिखते हैं

हमने अपना एप्लिकेशन सर्वर लिखा, जो PHP-RM के समान है, लेकिन इसमें अधिक कार्यक्षमता है। हमें सर्वर से क्या चाहिए था?

मौजूदा चौखटे के साथ गठबंधन करें। हम बाजार पर लगभग सभी रूपरेखाओं के साथ लचीला एकीकरण करना चाहते हैं। मुझे ऐसा टूल लिखने का मन नहीं है जो किसी विशेष मामले में ही काम करता हो।

सर्वर और एप्लिकेशन के लिए अलग-अलग प्रक्रियाएं । एक गर्म रिबूट की संभावना, ताकि स्थानीय रूप से विकसित होने पर, F5 दबाएं और नए अपडेट किए गए कोड देखें, साथ ही साथ उन्हें व्यक्तिगत रूप से विस्तारित करने में सक्षम हों।

उच्च गति और स्थिरता । फिर भी, हम एक HTTP सर्वर लिख रहे हैं।

आसान विस्तार । हम न केवल HTTP-Server के रूप में सर्वर का उपयोग करना चाहते हैं, बल्कि एक कतार सर्वर या gRPC सर्वर जैसे व्यक्तिगत परिदृश्यों के लिए भी।

जहां भी संभव हो बॉक्स से बाहर काम करें : विंडोज, लिनक्स, एआरएम सीपीयू।

हमारे आवेदन के लिए बहुत तेजी से बहु-थ्रेडेड एक्सटेंशन लिखने की क्षमता।

जैसा कि आप पहले से ही समझ चुके हैं, हम गोलंग में लिखेंगे।

रोडरनर सर्वर

PHP सर्वर बनाने के लिए, आपको 4 मुख्य समस्याओं को हल करना होगा:

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

प्रक्रियाओं के बीच बातचीत के प्रकार

सबसे पहले, चलिए गोलांग और PHP प्रक्रियाओं के बीच संचार समस्या को हल करते हैं। हमारे पास कई तरीके हैं।

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

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

अपना परिवहन प्रोटोकॉल लिखना - गोरिज

हम एक सरल पथ पर चले गए जिसका उपयोग लिनक्स सिस्टम पर लगभग सभी समाधानों में किया जाता है - हमने परिवहन प्रोटोकॉल का उपयोग किया। यह मानक PIPES और UNIX / TCP SOCKETS के शीर्ष पर लिखा गया है ।

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

किसी भी प्रोटोकॉल के साथ, नींव एक डेटा पैकेट है। हमारे मामले में, पैकेट में 17 बाइट्स का एक निश्चित हेडर होता है।



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



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

गोलांग और पीएचपी में प्रोटोकॉल को लागू करने के लिए, हमने मानक उपकरणों का उपयोग किया।

गोलांग पर: मानक पाइप और UNIX / TCP सॉकेट के साथ काम करने के लिए एन्कोडिंग / बाइनरी लाइब्रेरी और io और नेट लाइब्रेरी।

PHP में: बाइनरी डेटा पैक / अनपैक के साथ काम करने के लिए परिचित फ़ंक्शन और पाइप और सॉकेट के लिए एक्सटेंशन स्ट्रीम और सॉकेट।

कार्यान्वयन के दौरान एक दिलचस्प दुष्प्रभाव सामने आया। हमने इसे मानक गोलंग नेट / आरपीसी लाइब्रेरी के साथ एकीकृत किया, जो हमें सीधे आवेदन में गोलंग से सेवा कोड को कॉल करने की अनुमति देता है।

हम एक सेवा लिखते हैं:

//  sample type  struct{} // Hi returns greeting message. func (a *App) Hi(name string, r *string) error { *r = fmt.Sprintf("ll, %s!", name) return nil } 

थोड़ी मात्रा में कोड के साथ, हम इसे एप्लिकेशन से कॉल करते हैं:

 <?php use Spiral\Goridge; require "vendor/autoload.php"; $rpc = new Goridge\RPC( new Goridge\SocketRelay("127.0.0.1", 6001) ); echo $rpc->call("App.Hi", "Antony"); 

PHP प्रक्रिया प्रबंधक

सर्वर का अगला भाग PHP के श्रमिकों का प्रबंधन है।


वर्कर एक PHP प्रक्रिया है जिसे हम लगातार गोलंग से देखते हैं। हम STDERR फ़ाइल में इसकी त्रुटियों के लॉग को इकट्ठा करते हैं, गोरिज परिवहन प्रोटोकॉल के माध्यम से कार्यकर्ता से संवाद करते हैं, और मेमोरी खपत, कार्य निष्पादन, और अवरुद्ध करने के आंकड़े एकत्र करते हैं।

कार्यान्वयन सरल है - यह ओएस / निष्पादन, रनटाइम, सिंक, परमाणु की मानक कार्यक्षमता है। श्रमिकों को बनाने के लिए हम वर्कर फैक्टरी का उपयोग करते हैं।


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

टास्क बैलेंसर

सर्वर का तीसरा भाग प्रदर्शन के लिए सबसे महत्वपूर्ण है।

कार्यान्वयन के लिए, हम मानक गोलांग कार्यक्षमता का उपयोग करते हैं - एक बफर चैनल । विशेष रूप से, हम कई कार्यकर्ता बनाते हैं और उन्हें इस चैनल में एक LIFO स्टैक के रूप में डालते हैं।

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

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

यदि कोई त्रुटि होती है, तो उपयोगकर्ता को एक त्रुटि प्राप्त होगी, क्योंकि कार्यकर्ता नष्ट हो जाएगा। हम वर्कर पूल और वर्कर फैक्ट्री को एक समान प्रक्रिया बनाने और स्टैक पर इसे बदलने के लिए कहते हैं। यह सिस्टम को PHP-FPM के साथ सादृश्य द्वारा श्रमिकों को फिर से बनाने के द्वारा घातक त्रुटियों की स्थिति में भी काम करने की अनुमति देता है।


नतीजतन, यह एक छोटी प्रणाली को लागू करने के लिए निकला जो बहुत जल्दी काम करता है - कार्यकर्ता आवंटन के लिए 200 एनएस । यह घातक त्रुटियों के मामले में भी काम करने में सक्षम है। एक समय में प्रत्येक कार्यकर्ता केवल एक कार्य करता है, जो हमें क्लासिक ब्लॉकिंग दृष्टिकोण का उपयोग करने की अनुमति देता है।

सक्रिय निगरानी

दोनों प्रक्रिया प्रबंधक और कार्य बैलेंसर का एक अलग हिस्सा सक्रिय निगरानी प्रणाली है।


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

HTTP स्टैक

अंतिम और सरल भाग।

इसे कैसे लागू किया जाता है:

• गोलंग पक्ष पर एक HTTP बिंदु उठाता है;
• हम एक अनुरोध प्राप्त करते हैं;
• PSR-7 प्रारूप में परिवर्तित;
• पहले निशुल्क कार्यकर्ता को अनुरोध भेजें;
• PSR-7 ऑब्जेक्ट में अनुरोध को अनपैक करें;
• हम प्रक्रिया करते हैं;
• हम उत्तर उत्पन्न करते हैं।

कार्यान्वयन के लिए, हमने मानक गोलांग नेट / एचटीटीपी पुस्तकालय का उपयोग किया । यह एक प्रसिद्ध पुस्तकालय है जिसमें कई एक्सटेंशन हैं। HTTPS और HTTP / 2 प्रोटोकॉल पर काम करने में सक्षम।

PHP की तरफ, हमने PSR-7 मानक का उपयोग किया । यह कई एक्सटेंशन और मिडलवेर्स के साथ एक स्वतंत्र ढांचा है । PSR-7 डिजाइन में अपरिवर्तनीय है , जो लंबे समय तक रहने वाले अनुप्रयोगों की अवधारणा के साथ अच्छी तरह से फिट बैठता है और वैश्विक क्वेरी त्रुटियों से बचा जाता है।

गोलंग और पीएसआर -7 दोनों संरचनाएं समान हैं, जिसने एक भाषा से दूसरी भाषा में अनुरोध को मैप करने के लिए समय की बचत की है।

सर्वर को शुरू करने के लिए एक न्यूनतम बंधन की आवश्यकता होती है:

 http: address: 0.0.0.0:8080 workers: command: "php psr-worker.php" pool: numWorkers: 4 

इसके अलावा, संस्करण 1.3.0 से विन्यास के अंतिम भाग को छोड़ा जा सकता है।

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

PHP की ओर, हम एक प्राथमिक लूप लिखते हैं जो PSR-7 अनुरोध प्राप्त करता है, इसे संसाधित करता है, और सर्वर पर प्रतिक्रिया या त्रुटि देता है।

 while ($req = $psr7->acceptRequest()) { try { $resp = new \Zend\Diactoros\Response(); $resp->getBody()->write("hello world"); $psr7->respond($resp); } catch (\Throwable $e) { $psr7->getWorker()->error((string)$e); } } 

विधानसभा। सर्वर को लागू करने के लिए, हमने एक घटक दृष्टिकोण के साथ एक आर्किटेक्चर चुना। यह परियोजना की आवश्यकताओं के लिए सर्वर को इकट्ठा करना संभव बनाता है, आवेदन की आवश्यकताओं के आधार पर व्यक्तिगत टुकड़ों को जोड़ या हटा देता है।

 func main() { rr.Container.Register(env.ID, &env.Service{}) rr.Container.Register(rpc.ID, &rpc.Service{}) rr.Container.Register(http.ID, &http.Service{}) rr.Container.Register(static.ID, &static.Service{}) rr.Container.Register(limit.ID, &limit.Service{} // you can register additional commands using cmd.CLI rr.Execute() } 

मामलों का उपयोग करें

सर्वर का उपयोग करने और संरचना को संशोधित करने के विकल्पों पर विचार करें। शुरू करने के लिए, क्लासिक पाइपलाइन पर विचार करें - अनुरोधों के साथ सर्वर का काम।

प्रतिरूपकता

सर्वर एक HTTP बिंदु के लिए अनुरोध प्राप्त करता है और इसे मिडलवेयर के एक सेट से गुजरता है, जिसे गोलंग में लिखा गया है। एक आने वाले अनुरोध को एक कार्य में बदल दिया जाता है जिसे कार्यकर्ता समझता है। सर्वर कार्यकर्ता को कार्य देता है और उसे वापस लौटाता है।



उसी समय, कार्यकर्ता, गोरिज प्रोटोकॉल का उपयोग करते हुए, सर्वर के साथ संचार करता है, अपनी स्थिति की निगरानी करता है और डेटा को उसमें स्थानांतरित करता है।

गोलंग पर मिडिलवेयर: प्राधिकरण

यह पहली बात है। हमारे आवेदन में, हमने JWT टोकन द्वारा उपयोगकर्ता को अधिकृत करने के लिए मिडलवेयर लिखा था। किसी अन्य प्रकार के प्राधिकरण के लिए मिडलवेयर उसी तरह लिखा जाता है। दर-सीमक या सर्किट-ब्रेकर लिखने के लिए एक बहुत ही सामान्य और सरल कार्यान्वयन है।



प्राधिकरण त्वरित है । यदि अनुरोध मान्य नहीं है - बस इसे PHP एप्लिकेशन पर न भेजें और बेकार कार्यों को संसाधित करने पर संसाधनों को बर्बाद न करें।

निगरानी

दूसरा उपयोग मामला। हम सीधे गोलंग मिडलवेयर में निगरानी प्रणाली को एकीकृत कर सकते हैं। उदाहरण के लिए, प्रोमेथियस, प्रतिक्रिया बिंदुओं की गति पर आंकड़े एकत्र करने के लिए, त्रुटियों की संख्या।



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

ट्रेसिंग और लॉगिंग वितरित की गई

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



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

अपना क्वेरी इतिहास रिकॉर्ड करें

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



हमने मॉड्यूल कैसे लागू किया?

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



हम एक WebSocket सर्वर लिख रहे हैं । एक WebSocket सर्वर या पुश अधिसूचना सर्वर को लागू करना एक तुच्छ कार्य बन रहा है।

• सर्वर स्तर पर गोलंग सेवा।
• संचार के लिए हम गोरिज का उपयोग करते हैं।
• PHP में पतली सर्विस लेयर।
• हम अधिसूचना सर्वर को लागू करते हैं।

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



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



दिलचस्प बात यह है कि कार्यकर्ता के अंदर उपलब्ध एनवी वैरिएबल सिस्टम के भीतर वैश्विक नहीं हैं। यह कंटेनर सुरक्षा को थोड़ा सुधारता है।

PHP में गोलंग लाइब्रेरी इंटीग्रेशन

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



हमने प्रलेखन पृष्ठों को अनुक्रमित किया: हमने उन्हें बोल्ट डीबी में रखा, जिसके बाद हमने MySQL जैसे वास्तविक डेटाबेस के बिना एक पूर्ण-पाठ खोज की, और एलिस्टिक्स खोज जैसे खोज क्लस्टर के बिना। परिणाम एक छोटी परियोजना थी जहां कुछ कार्यक्षमता PHP में है, लेकिन खोज गोलंग में है।

लैम्ब्डा फंक्शंस को लागू करना

आप आगे जा सकते हैं और HTTP लेयर से पूरी तरह छुटकारा पा सकते हैं । इस मामले में, लागू करना, उदाहरण के लिए, लैम्ब्डा फ़ंक्शन एक सरल कार्य है।



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

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

PHP के लिए gRPC

अधिक कठिन विकल्प HTTP लेयर को gRPC लेयर से बदलना है। यह पैकेज GitHub पर उपलब्ध है ।


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

कतार का सर्वर

अंतिम और सबसे दिलचस्प विकल्प कतार सर्वर का कार्यान्वयन है।


PHP की तरफ, हम सब करते हैं एक बाइनरी पेलोड मिलता है, इसे अनपैक करें, काम करें, और सर्वर को सफलता के बारे में बताएं। गोलंग की तरफ, हम पूरी तरह से दलालों के साथ संबंध बनाने में लगे हुए हैं। यह RabbitMQ, Amazon SQS या Beanstalk हो सकता है।

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

हम PHP और गोलंग दोनों में इन अनुरोधों को संसाधित कर सकते हैं, और उन्हें दोनों पक्षों पर पंक्तिबद्ध कर सकते हैं:

• गोरिज प्रोटोकॉल गोरिज आरपीसी के माध्यम से पीएचपी;
• गोलांग से - एसडीके पुस्तकालय के साथ संचार।

यदि पेलोड गिरता है, तो पूरा उपभोक्ता नहीं गिरता है, लेकिन केवल एक अलग प्रक्रिया है। सिस्टम तुरंत इसे उठाता है, कार्य अगले कार्यकर्ता को भेजा जाता है। यह आपको गैर-स्टॉप कार्य करने की अनुमति देता है।

हमने दलालों में से एक को सीधे सर्वर मेमोरी में लागू किया और गोलंग कार्यक्षमता का उपयोग किया। यह हमें अंतिम स्टैक चुनने से पहले कतारों का उपयोग करके एक आवेदन लिखने की अनुमति देता है। हम एप्लिकेशन को स्थानीय रूप से उठाते हैं, इसे शुरू करते हैं, और हमारे पास कतारें हैं जो स्मृति में काम करती हैं और उसी तरह से व्यवहार करती हैं जैसे वे RabbitMQ, Amazon SQS या बीनस्टॉक पर व्यवहार करेंगे।

ऐसे हाइब्रिड बंडल में दो भाषाओं का उपयोग करते समय, यह याद रखने योग्य है कि उन्हें कैसे अलग किया जाए।

अलग डोमेन डोमेन

गोलंग एक बहु-थ्रेडेड और तेज़ भाषा है जो बुनियादी ढांचे के तर्क और उपयोगकर्ता की निगरानी और प्राधिकरण तर्क लिखने के लिए उपयुक्त है।

यह डेटा स्रोतों तक पहुंचने के लिए कस्टम ड्राइवरों को लागू करने के लिए भी उपयोगी है - ये कतारें हैं, उदाहरण के लिए, काफ्का, कैसेंड्रा।

PHP व्यावसायिक तर्क लिखने के लिए एक बेहतरीन भाषा है।

यह HTML प्रतिपादन, ORM और डेटाबेस के साथ काम करने के लिए एक अच्छी प्रणाली है।

उपकरण की तुलना

Habré पर कई महीने पहले PHP-FPM, PHP-PM, React-PHP, Roadrunner और अन्य उपकरणों की तुलना की गई थी। बेंचमार्क असली सिम्फनी 4 के साथ एक परियोजना पर आयोजित किया गया था।

लोड के तहत रोडरनर अच्छे परिणाम दिखाता है और सभी सर्वरों से आगे है। PHP-FPM की तुलना में, प्रदर्शन 6-8 गुना अधिक है।


उसी बेंचमार्क में, रोडरनर ने एक भी अनुरोध नहीं खोया, सब कुछ 100% काम किया। दुर्भाग्य से, React-PHP ने लोड के तहत 8-9 अनुरोध खो दिए - यह अस्वीकार्य है। हम चाहेंगे कि सर्वर दुर्घटनाग्रस्त न हो और पूरी तरह से काम करे।


गिटहब पर सार्वजनिक पहुंच में रोडरनर के प्रकाशन के बाद से, हमें 30,000 से अधिक इंस्टॉलेशन मिले हैं। समुदाय ने हमें एक्सटेंशन, सुधार का एक विशिष्ट सेट लिखने में मदद की है और विश्वास है कि समाधान में जीवन का अधिकार है।

यदि आप एप्लिकेशन को महत्वपूर्ण रूप से गति देना चाहते हैं, तो रोडरनर अच्छा है , लेकिन अभी तक अतुल्यकालिक PHP में कूदने के लिए तैयार नहीं हैं । यह एक समझौता है जिसे एक निश्चित मात्रा में प्रयास की आवश्यकता होगी, लेकिन कोड आधार के पूर्ण पुनर्लेखन के रूप में महत्वपूर्ण नहीं है।

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

परिणाम

हमें इस सर्वर को लिखने और हमारे उत्पादन ढांचे में इसका उपयोग करने से क्या मिला।

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

PHP डेवलपर्स PHP रूस के लिए अगले पेशेवर सम्मेलन केवल अगले साल। अभी के लिए, हम निम्नलिखित प्रदान करते हैं:

• यदि आप गो भाग में रुचि रखते हैं और इस भाषा पर स्विच करने के पक्ष में और अधिक विवरण जानना चाहते हैं या तर्क सुनना चाहते हैं तो गोलंगकॉन्फ़ पर ध्यान दें । यदि आप अपना अनुभव साझा करने के लिए तैयार हैं, तो कृपया अमूर्त भेजें ।
• मॉस्को में हाईलाड ++ में भाग लें, अगर आपके लिए सब कुछ महत्वपूर्ण है जो उच्च प्रदर्शन से जुड़ा है, तो 7 सितंबर से पहले एक रिपोर्ट सबमिट करें, या एक टिकट बुक करें।
• अन्य की तुलना में पहले PHP रूस 2020 के लिए एक निमंत्रण प्राप्त करने के लिए न्यूज़लेटर और टेलीग्राम चैनल की सदस्यता लें।