🧘🏾 🕯️ 🏇🏻 लोहा या अनुकूलन? PHP, Avito और Mamba - PHP प्रदर्शन के बारे में 🚀 🏄 😈

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

इसलिए, हमारे कार्यालय में PHP डेवलपर्स के समुदाय की तीसरी बैठक का विषय हमने बैकेंड प्रदर्शन किया और सहयोगियों और Avito और Mamba से चर्चा के लिए आमंत्रित किया।

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

और 15 फरवरी को, अगली लॉगइन PHP मीटअप : लीगेसी पर चर्चा करें।

हमने चर्चा के केवल उस भाग का ही खंडन किया है, जो हमें सबसे दिलचस्प लगा। पूर्ण संस्करण वीडियो पर उपलब्ध है।

विशेषज्ञों:

शिमोन कटावे, कोर सर्विसेज अवितो में डेवलपमेंट यूनिट के प्रमुख
पावेल मुराज़ाकोव pmurzakovPHP, PHP टिम्लेड में
मिखाइल ब्यॉयलोव mipxtx, मम्बा के आईटी निदेशक

अपने अभ्यास से अनुकूलन के बारे में एक कहानी बताएं: भव्य सफलता या भव्य असफलता एक ऐसी चीज है जिसे साझा करना दिलचस्प है।

मिखाइल बायलोव, माम्बा

मेरे पास एक दृष्टांत है।

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

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

जो समाधान पहले आते हैं, वे हमेशा सही नहीं होते हैं। अपने अनुरोधों के निशान, लॉग और बेंचमार्क को बेहतर देखें और सीधे ब्रेक न करें। यहाँ एक कहानी है।

पैवेल मुरज़कोव, Badoo

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

इन बिंदुओं में से एक पर, हमने एक पूरे समूह की पहचान की जो PHP स्क्रिप्ट में विभिन्न गैर-इष्टतम चीजों की तलाश में था और इसे अनुकूलित कर रहा था। यह सचमुच "ड्रॉप द्वारा ड्रॉप" हुआ: यहां उन्हें एक प्रतिशत मिला, वहां उन्हें एक प्रतिशत मिला - कई लोगों ने एक महीने के भीतर एक प्रतिशत पाया। किसी समय, हमारी सिसनी पास में थीeinstein_man। उसने यह देखने का फैसला किया कि वह क्या कर सकता है: वह शाम को चला गया, परफेक्ट लॉन्च किया, पीएचपी एक्सटेंशन में कुछ समस्याओं का पता चला - और शाम के जोड़े में सब कुछ 13% से तेज कर दिया!

शिमोन कटाव, एविटो

मेरी दो कहानियां हैं। एक फाइल के बारे में, दूसरा सुपर डेवलपर के बारे में।

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

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

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

हमें बताएं, आपका PHP क्लस्टर आकार क्या है, इसे कैसे कॉन्फ़िगर किया गया है - कम से कम PHP-FPM, या शायद कहीं अपाचे ने मुसीबत में डाल दिया है?

मिखाइल बायलोव, माम्बा

हमारे पास लगभग 15,000 आरपीएस हैं। 80 FPM सर्वर का एक क्लस्टर कई साल पहले खरीदा गया था। प्रत्येक क्लस्टर पर, FPM (अधिकतम 50 चिल्ड अधिकतम) को स्टैटिक्स में लॉन्च किया जाता है। इसने प्राइम टाइम में लगभग दस की ऊंचाई पर लोड किया। औसत प्रतिक्रिया समय 100 एमएस है, और हम इसे पकड़ने की कोशिश करते हैं (जब यह 100 एमएस से अधिक हो जाता है, तो हम ब्रेकिंग टुकड़ों की खोज शुरू करते हैं)।

हमारी अपनी प्रदर्शन निगरानी प्रणाली है। हमने कोड में बहुत सारे काउंटरों को तितर-बितर कर दिया, लगभग 120 प्रति अनुरोध। हम PHP में कोड के अंदर होने वाली बहुत सी घटनाओं की निगरानी करते हैं।

पैवेल मुरज़कोव, Badoo

हमारे साथ सब कुछ मानक है: nginx, PHP-FPM। एफपीएम के साथ लगभग 600 सर्वर। यदि PHP के बारे में बिल्कुल भी बात करें, तो, संभवतः, विभिन्न प्रयोजनों के लिए लगभग 300 अधिक सर्वर हैं, जैसे स्क्रिप्ट, बैक-ऑफ़िस और अन्य।

कॉन्फ़िगरेशन सुविधाओं में से, दो हैं। सबसे पहले, हमारे पास BMA प्रॉक्सी है - यह मोबाइल के लिए एक प्रॉक्सी है। अर्थात्, निगनेक्स में एक अनुरोध आने से पहले, यह एक विशेष प्रॉक्सी को मिलता है जो एक स्थायी कनेक्शन रखता है और नग्नेक्स को अनुरोध भेजता है। दूसरी विशेषता - कभी-कभी आपको CLI opcache को बंद करने की आवश्यकता होती है (हमने इसे स्क्रिप्टिंग मशीनों पर चालू कर दिया है)। एक बार हमने इसे बंद नहीं किया और इस पर 30% सीपीयू खो दिया। अपनी गलती का एहसास होने के बाद, वे हैरान थे कि आप एक सेटिंग से कितना बचा सकते हैं।

हमारे पास PHP पैच हैं, लेकिन वे प्रदर्शन से संबंधित नहीं हैं।

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

शिमोन कटाव, एविटो

हमारे पास प्रति मिनट (~ 33 kRPS) लगभग 2 मिलियन अनुरोध हैं। PHP में लिखा गया एक अखंड आवेदन 11 वर्षों से अधिक के लिए लिखा गया है। यह तेजी से विकास के चरण में है। जब कंपनी शुरू हुई, तो 65 भौतिक सर्वरों पर 65 एलएक्ससी थे। आवेदन के साथ प्रत्येक कंटेनर पर, मैट्रिक्स और लॉगिंग के लिए PHP-FPM, nginx और सहायक सॉफ्टवेयर चल रहे हैं। कुछ खास नहीं।

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

आप प्रदर्शन को कैसे मापते हैं? आप क्लाइंट के रिस्पांस टाइम को किस टूल से मापते हैं?

मिखाइल बायलोव, माम्बा

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

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

शिमोन कटाव, एविटो

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

पैवेल मुरज़कोव, Badoo

सब कुछ वैसा ही है जैसा दोस्तों ने हमें बताया। PHP के लिए क्लासिक Pinba का उपयोग करना, हम PHP के संदर्भ में एक PHP स्क्रिप्ट के चलने के समय को मापते हैं। लेकिन हमारे पास भी है, उदाहरण के लिए, नगनेक्स के लिए पिनबा, जो नगीनेक्स के दृष्टिकोण से प्रतिक्रिया समय को मापता है। हम क्लाइंट पर मैट्रिक्स भी एकत्र करते हैं।

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

शिमोन कटाव, एविटो

हमारे यहां PHP एप्लिकेशन खुद को मापता है और register_shutdown_function () में मैट्रिक्स निकालता है। प्रत्येक LXC में एक StatsD सर्वर होता है, जो इन मेट्रिक्स को इकट्ठा करता है और उन्हें संग्राहकों के माध्यम से ग्रेफाइट क्लस्टर (ClickHouse सहित) में भेजता है, जहाँ डेटा संग्रहीत होता है। यह एक आत्म निदान है।

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

प्रदर्शन ट्रैक के लिए आपके पास क्या उपकरण हैं? आप सबसे अधिक बार क्या उपयोग करते हैं?

मिखाइल बायलोव, माम्बा

हमने अपना टूल लिखा। जब पिनबा अभी बाहर आया था - 2012 में, बहुत समय पहले - यह MySQL के लिए एक मॉड्यूल था जिसे यूडीपी के ऊपर कुछ इस तरह से मिला। ग्राफिक्स को निकालना मुश्किल था, यह प्रदर्शन के लिए बहुत अनुकूलित नहीं था। और हमने अपनी बात को बेटर दैन पिनबा लिखने से बेहतर कुछ नहीं बताया। यह सिर्फ एक काउंटर सर्वर है जो उन्हें PHP क्लाइंट से स्वीकार करता है।

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

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

यह देखा जा सकता है जब प्रदर्शन गिरता है। हम इस तरह खोदना शुरू कर रहे हैं। PHP 7 से पहले, हमने XHProf का उपयोग किया, फिर इसने हमारे साथ निर्माण करना बंद कर दिया। इसलिए, हमने Xdebug पर स्विच किया। Xdebug हम समस्या के दिखाई देने पर ही प्रहार करते हैं।

पैवेल मुरज़कोव, Badoo

यह एक आम धारणा है कि XHProf PHP 7 में नहीं बनने वाला है। यह सच है, लेकिन केवल भाग में। यदि आप विज़ार्ड से XHProf लेते हैं, तो यह वास्तव में नहीं होगा। लेकिन अगर GitHub पर आप एक्सपेरिमेंटल (या ऐसा ही कुछ) नामक शाखा में जाते हैं, तो PHP 7, उत्पादन के लिए सब कुछ ठीक काम करता है। जांच की गई।

मिखाइल बायलोव, माम्बा

नहीं, मैंने स्विच किया। इसने मेरे लिए काम नहीं किया।

पैवेल मुरज़कोव, Badoo

मैं पिनबा के बारे में जोड़ना चाहता हूं। आप कुछ हद तक नबी बन गए हैं। हमने, कुछ बिंदु पर, उत्पादकता खो दी है। हमने Pinba2 बनाया , जो बहुत तेज है। इसका उपयोग पिनाबा के प्रतिस्थापन के रूप में किया जा सकता है।

शिमोन कटाव, एविटो

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

पैवेल मुरज़कोव, Badoo

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

शिमोन कटाव, एविटो

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

चूंकि हम लोहे के बिंदु पर पहुंच गए हैं: क्या कोई आपकी कंपनी में योजनाबद्ध तरीके से योजनाबद्ध तरीके से लगा हुआ है? यह प्रक्रिया कैसे बनाई जाती है?

शिमोन कटाव, एविटो

एक अखंड एप्लिकेशन कम से कम पांच साल के लिए कम से कम 65 LXC चलाता है। हम कोड का अनुकूलन करते हैं, इसमें सुधार करते हैं: इसके पास पर्याप्त संसाधन हैं। हमारी मुख्य क्षमता योजना कुबेरनेट्स में जाती है, जहां लगभग 400 अधिक या कम रहने वाले माइक्रोसर्विसेज पीएचपी / गो में लिखे गए हैं। हम धीरे-धीरे मोनोलिथ से टुकड़े काट रहे हैं, लेकिन यह अभी भी बढ़ रहा है। हम उसे रोक नहीं सकते।

सामान्य तौर पर, PHP एक शांत भाषा है। यह व्यापार तर्क को जल्दी से लागू करता है।

पैवेल मुरज़कोव, Badoo

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

हम खुद को बार सेट करते हैं: हमें 60% से अधिक क्लस्टर "नहीं खाना" चाहिए। 60%, और 95% नहीं, क्योंकि हमारे पास हाइपरट्रेडिंग है, जो इसके अलावा प्रोसेसर से अधिक निचोड़ता है, जितना आप इसके बिना निचोड़ सकते हैं। इसके लिए, हम इस तथ्य से भुगतान करते हैं कि हमारे सीपीयू खपत के 50% के बाद हम अप्रत्याशित तरीके से बढ़ सकते हैं, क्योंकि हाइपर-फैलने वाली गुठली पूरी तरह से ईमानदार नहीं हैं।

मिखाइल बायलोव, माम्बा

हम एक तैनाती करते हैं और देखते हैं कि हमारे साथ कुछ विफल हो गया है - ऐसी क्षमता योजना। आँख से! हमारे पास उत्पादकता का एक निश्चित मार्जिन है जो हमें ऐसा करने की अनुमति देता है। हम उससे चिपके रहने की कोशिश करते हैं।

इसके अलावा, हम फैक्टम ऑप्टिमाइज़ेशन पोस्ट करते हैं। जब हम देखते हैं कि कुछ गिर गया है, तो हम वापस रोल करते हैं यदि सब कुछ पूरी तरह से खराब है। लेकिन व्यावहारिक रूप से ऐसा नहीं होता है।

या हम सिर्फ यह देखते हैं कि "यहां इष्टतम नहीं है, अब हम जल्दी से सब कुछ ठीक कर देंगे और सब कुछ उसी तरह काम करेगा जैसा इसे करना चाहिए।"

हम विशेष रूप से परेशान नहीं करते हैं: यह बहुत मुश्किल है, और निकास बहुत बड़ा नहीं होगा।

आप microservices के बारे में बात कर रहे हैं। वे कैसे बातचीत करते हैं? क्या यह REST या आप बाइनरी प्रोटोकॉल का उपयोग कर रहे हैं?

शिमोन कटाव, एविटो

काफ्का का उपयोग सेवाओं के बीच घटनाओं को भेजने के लिए किया जाता है, JSON-RPC का उपयोग सेवाओं के बीच बातचीत सुनिश्चित करने के लिए किया जाता है, लेकिन पूर्ण नहीं, लेकिन इसका सरलीकृत संस्करण, जिससे हम छुटकारा नहीं पा सकते हैं। वहाँ तेजी से कार्यान्वयन कर रहे हैं: एक ही protobuf, gRPC। यह हमारी योजनाओं में है, लेकिन निश्चित रूप से प्राथमिकता नहीं है। 400 से अधिक microservices के साथ, यह उन सभी को नए प्रोटोकॉल में पोर्ट करना कठिन है। अनुकूलन के लिए अन्य स्थानों के टन हैं। हम निश्चित रूप से अब तक नहीं हैं।

पैवेल मुरज़कोव, Badoo

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

मिखाइल बायलोव, माम्बा

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

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

मिखाइल बायलोव, माम्बा

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

पैवेल मुरज़कोव, Badoo

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

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

शिमोन कटाव, एविटो

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

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

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

मैं जानना चाहूंगा कि आपके लिए मानक बैकएंड प्रतिक्रिया समय क्या है जो आप अनुसरण कर रहे हैं? जब आप समझते हैं कि आपको आगे अनुकूलन करने की आवश्यकता है, या समाप्त करने का समय क्या है? क्या "अस्पताल का औसत" मूल्य है?

पैवेल मुरज़कोव, Badoo

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

मिखाइल बायलोव, माम्बा

हम HTML रेंडरिंग से एपीआई अनुरोधों पर स्विच कर रहे हैं। यहां, वास्तव में, एपीआई बड़े, भारी HTML प्रतिक्रिया की तुलना में बहुत तेजी से प्रतिक्रिया करता है। इसलिए, अंतर करना मुश्किल है, उदाहरण के लिए, 100 एमएस का मूल्य। हमने 200 एमएस पर ध्यान केंद्रित किया। फिर PHP 7 हुआ - और हमने 100 एमएस पर ध्यान केंद्रित करना शुरू किया। यह "अस्पताल के लिए औसत" है। यह एक बहुत अस्पष्ट मीट्रिक है, जो बताता है कि यह कम से कम वहाँ देखने का समय है। और इसलिए हम तैनाती पर ध्यान केंद्रित करते हैं और इसके बाद प्रतिक्रिया समय कूदते हैं।

शिमोन कटाव, एविटो

हमने प्रदर्शन टीमों में से एक का स्केच किया। सहकर्मियों ने मापा कि विभिन्न परिदृश्यों के तहत पेज लोडिंग को गति देकर कंपनी कितनी अधिक कमाई करती है। हमने गणना की कि कितने अधिक खरीदार, लेनदेन, कॉल, संक्रमण और इतने पर चल रहे हैं। इन आंकड़ों के अनुसार, यह समझा जा सकता है कि कुछ बिंदु पर, त्वरण समझ में आता है। उदाहरण के लिए, यदि 90 एमएस से पन्नों में से किसी एक का प्रतिक्रिया समय 70 एमएस हो गया, तो इसने खरीदारों को + 2% दिया। और यदि आप 70 एमएस से 60 एमएस तक तेजी लाते हैं, तो पहले से ही खरीदारों का 0.1% है, जो आम तौर पर त्रुटि में शामिल है। जैसे दोस्तों के साथ, सब कुछ उस पेज पर बहुत कुछ निर्भर करता है जिस पर हम काम कर रहे हैं। सामान्य तौर पर, एविटो 75 वें प्रतिशतक - लगभग 75 एमएस। मेरी राय में, यह धीमा है। अब हम अनुकूलन के लिए स्थानों की तलाश कर रहे हैं। माइक्रोसर्विस में संक्रमण से पहले, हमारे लिए सब कुछ बहुत तेजी से हुआ, और हम प्रदर्शन को अनुकूलित करने की कोशिश कर रहे हैं।

और शाश्वत प्रश्न: लोहा या अनुकूलन? कैसे समझें कि क्या यह हार्डवेयर खरीदने के लायक है या अनुकूलन में निवेश करना बेहतर है? सीमा कहां है?

शिमोन कटाव, एविटो

मेरी राय: एक वास्तविक प्रोग्रामर अनुकूलन है। यह मुझे लगता है कि बड़ी कंपनियों में जैसे कि Badoo, मेरा, यांडेक्स, विभिन्न स्तरों के कई डेवलपर्स हैं। जूनियर डेवलपर्स / इंटर्न और अग्रणी डेवलपर्स दोनों हैं। यह मुझे लगता है कि अनुकूलन / संशोधन के लिए स्थानों की संख्या हमेशा वहां जोड़ी जाती है। लोहा अंतिम चरण है। 65 LXC पर एक मोनोलिथ के लिए, हमने बहुत लंबे समय तक लोहा नहीं जोड़ा है। CPU उपयोग - 20%। हम पहले से ही उन्हें कुबेरनेट समूह में स्थानांतरित करने के बारे में सोच रहे हैं।

पैवेल मुरज़कोव, Badoo

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

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

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

मिखाइल बायलोव, माम्बा

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

शिमोन कटाव, एविटो

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

चूँकि हमारे पास एक PHP mitap है, इस वाक्यांश को ध्वनि चाहिए: हमें PHP की आवश्यकता क्यों है, क्योंकि हमारे पास हर समय ऐसी समस्याएं हैं? आइए, गो, सी, सी #, रस्ट, नोड.जेएस को फिर से लिखें!
क्या आपको लगता है कि पुनर्लेखन दृष्टिकोण आमतौर पर उचित है? क्या इस समस्या के समाधान के लिए कोई समस्या है जो इसे करने और इस समय निवेश करने के लायक है?

शिमोन कटाव, एविटो

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

एक नई भाषा का परिचय, मेरी राय में, ढेर और रोजगार के अवसरों के विस्तार के लिए समझ में आता है। अब अच्छे PHP डेवलपर्स को ढूंढना काफी कठिन है। अगर हम गोलंग को टेकराडार में पेश करते हैं, तो हम गोफर को किराए पर ले सकते हैं। बाजार पर कुछ PHP शॅनी और कुछ गॉफ़र्स हैं, और साथ में उनमें से पहले से ही बहुत सारे हैं। उदाहरण के लिए, हमारे पास एक प्रयोग था। हमने सी # डेवलपर्स को लिया जो नई भाषाएँ सीखने के लिए तैयार हैं - हमने बस हायरिंग स्टैक का विस्तार किया। यदि हम लोगों को बताते हैं कि हम उन्हें PHP में लिखना सिखाएँगे, तो वे कहते हैं कि यह बेहतर नहीं है। और अगर हम उन्हें पीएचपी में लिखने के लिए सीखने की पेशकश करते हैं, तो जाओ और अभी भी पायथन में लिखने का अवसर वादा करते हैं, तो लोग जवाब देने के लिए तैयार हैं। मेरे लिए, यह रोजगार के अवसरों का विस्तार है। अन्य भाषाओं में, कुछ चीजें हैं जो वास्तव में PHP में गायब हैं। लेकिन सामान्य तौर पर, PHP व्यावसायिक समस्याओं को सुलझाने और बड़ी परियोजनाओं को लागू करने के लिए सुपर पर्याप्त है।

पैवेल मुरज़कोव, Badoo

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

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

मिखाइल बायलोव, माम्बा

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

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

शिमोन कटाव, एविटो

Go in microservices का उपयोग करना आवश्यक नहीं है। कई सेवाएं PHP में लिखी गई हैं और एक स्वीकार्य प्रतिक्रिया समय है। उनका समर्थन करने वाली टीम ने खुद के लिए फैसला किया कि उन्हें व्यापार तर्क को बहुत जल्दी लिखने और सुविधाओं को पेश करने की आवश्यकता है। वे वास्तव में कभी-कभी गोफर्स की तुलना में तेजी से करते हैं।

हमारे पास गोफर्स को किराए पर देने, गो टू ट्रांसलेट करने की प्रवृत्ति है। लेकिन हमारे पास अभी भी अधिकांश कोड PHP में लिखे गए हैं, और इसलिए यह कम से कम कुछ और वर्षों के लिए होगा। कोई वास्तविक दौड़ नहीं है, हमने यह तय नहीं किया कि गो बेहतर है या बदतर। छह रिलीज रोजाना मोनोलिथ में लुढ़की जाती हैं। हमारी चैट "Avito Deploy" में उन कार्यों की एक सूची है जो तैनात हैं। प्रत्येक रिलीज़ में प्रति दिन कम से कम 20 कार्य किए जाते हैं: प्रति दिन कम से कम पाँच या छह रिलीज़, लगभग 80 कार्य जो लोग इन कार्यों पर करते हैं। यह सब PHP में किया जाता है।

? -, ?

,

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

विरासत का एक गुच्छा यह बताता है कि कोई भी पहले से ही वास्तव में विकास को धीमा नहीं करता है। ऐसे सैकड़ों मामले हैं जब कोई नया व्यक्ति किसी कंपनी में आता है और एक मृत कोड को फिर से तैयार करता है जिसे कभी नहीं बुलाया जाता है क्योंकि वह नहीं जानता है कि यह एक मृत कोड है।

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

मिखाइल बायलोव, माम्बा

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

प्रबंधक कार्य सेट करता है, आप इसका मूल्यांकन करते हैं। आप कहते हैं: "आप जानते हैं, यार, मैं ऐसा छह महीने तक करूँगा। क्या आप आधा साल बर्दाश्त करने के लिए तैयार हैं? ” वह कहता है: “नहीं, सोचने दो कि क्या काटना है, क्या छोड़ा जा सकता है। मूल रूप से आवश्यक है और चारों ओर खेलने के लिए क्या आवश्यक है। ” ऐसे ही चलता है।

पैवेल मुरज़कोव, Badoo

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

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

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

15 Badoo PHP Meetup. , : SuperJob, ManyChat, , Badoo FunCorp .

, , YouTube-. , - .

, .

लोहा या अनुकूलन? PHP, Avito और Mamba - PHP प्रदर्शन के बारे में

मिखाइल बायलोव, माम्बा

पैवेल मुरज़कोव, Badoo

शिमोन कटाव, एविटो

मिखाइल बायलोव, माम्बा

पैवेल मुरज़कोव, Badoo

शिमोन कटाव, एविटो

मिखाइल बायलोव, माम्बा

शिमोन कटाव, एविटो

पैवेल मुरज़कोव, Badoo

शिमोन कटाव, एविटो

मिखाइल बायलोव, माम्बा

पैवेल मुरज़कोव, Badoo

मिखाइल बायलोव, माम्बा

पैवेल मुरज़कोव, Badoo

शिमोन कटाव, एविटो

पैवेल मुरज़कोव, Badoo

शिमोन कटाव, एविटो

शिमोन कटाव, एविटो

पैवेल मुरज़कोव, Badoo

मिखाइल बायलोव, माम्बा

शिमोन कटाव, एविटो

पैवेल मुरज़कोव, Badoo

मिखाइल बायलोव, माम्बा

मिखाइल बायलोव, माम्बा

पैवेल मुरज़कोव, Badoo

शिमोन कटाव, एविटो

पैवेल मुरज़कोव, Badoo

मिखाइल बायलोव, माम्बा

शिमोन कटाव, एविटो

शिमोन कटाव, एविटो

पैवेल मुरज़कोव, Badoo

मिखाइल बायलोव, माम्बा

शिमोन कटाव, एविटो

शिमोन कटाव, एविटो

पैवेल मुरज़कोव, Badoo

मिखाइल बायलोव, माम्बा

शिमोन कटाव, एविटो

,

मिखाइल बायलोव, माम्बा

पैवेल मुरज़कोव, Badoo

More articles: