🐅 🔷 👈🏽 लंदन में एक दिन में पेश करें: इसे कैसे प्राप्त करें और आगे बढ़ने के बाद क्या करें 🕷️ 👶🏻 🌩️

हेलो, हेब्र!

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

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

प्रारूप ने अच्छा काम किया है, और हमारे पास फिर से कई खुले स्थान हैं, इसलिए हम एक नए पीएचपी हायरिंग इवेंट की घोषणा कर रहे हैं।

नियम समान हैं: 1 मार्च से पहले एक उच्च परीक्षा परिणाम दिखाएं , 21 या 22 मार्च को मॉस्को में साक्षात्कार को सफलतापूर्वक पास करें - और उसी दिन शर्त लंदन कार्यालय को एक प्रस्ताव प्राप्त करें।

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

कटौती के तहत, मैं आपको बताता हूं:

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

यदि आप एक PHP शानी हैं और लंदन जाना चाहते हैं, तो कैट में आपका स्वागत है!

टेस्ट कैसे पास करना है

परीक्षण में पाँच कार्य होते हैं। सटीक रूप से 90 मिनट निर्णय के लिए आवंटित किए जाते हैं: यह प्रक्रिया में देरी या ठहराव के लिए काम नहीं करेगा। शुरू करने से पहले, सुनिश्चित करें कि आपके पास पर्याप्त समय है।

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

2020-03-01 23:59:59 यूटीसी तक निर्णय किए जाते हैं। परीक्षण के परिणामों के आधार पर, हम लगभग 60 उम्मीदवारों का चयन करेंगे जिन्हें हम मॉस्को में साक्षात्कार के लिए आमंत्रित करेंगे।

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

सर्वर डेवलपमेंट टीम क्या करती है

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

हमारी टीम में 40 से अधिक लोग हैं। कार्य को दो बड़े भागों में विभाजित किया जा सकता है:

अनुप्रयोगों में नई कार्यक्षमता,
तकनीकी परियोजनाएं - उपकरण का सुधार, अनुकूलन, तकनीकी ऋण के साथ काम करना।

मैं उन सबसे दिलचस्प परियोजनाओं के बारे में बात करूंगा जिन्हें हमने पिछले दो वर्षों में लागू किया है।

उत्पाद में कूल चिप्स

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

"व्यक्तिगत" फ़ोटो भी छिपाना सीखे

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

जिस कार्य को हमें हल करना था, वह था कि "निजी" फ़ोटो (18+) को साधारण लोगों से अलग करने के लिए एप्लिकेशन को सिखाना और उन्हें चैट में दिखाया गया, जिससे प्राप्तकर्ता को खुद तय करने की अनुमति मिलती है कि क्या वह उन्हें अपनी संपूर्णता में देखना चाहता है।

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

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

जोड़ा गया ऑडियो और वीडियो चैट संदेश

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

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

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

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

आरएंडडी के बिना एमएल-मॉडल बनाने का तरीका सीखा

2018 में, हमने अपने डेटा पर मॉडल के प्रशिक्षण को स्वचालित करने के लिए अपना ढांचा बनाया। अब कोई भी बैकएंड डेवलपर R & D के सहयोगियों को आकर्षित किए बिना, स्वतंत्र रूप से अपने आवेदन के अनुरूप एक मॉडल का निर्माण कर सकता है।

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

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

परिणामों का मूल्यांकन करने के बाद, हमने लिंक पर क्लिक करने की कम से कम संभावना वाले ईमेल भेजना बंद कर दिया। इसके कारण हम:

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

लॉन्च की गई वीडियो स्ट्रीमिंग

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

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

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

Arbat पर उपयोगकर्ता संदेश प्रसारित करें

यह एक बहुत ही असामान्य प्रचार था: सभी अक्टूबर, बुश के उपयोगकर्ताओं ने मास्को में नोवी आर्बट पर स्थित एक विशाल वीडियो बिलबोर्ड पर संदेश भेजे। एक महीने में, 23,000 संदेश हमें भेजे गए, जिनमें से 12,000 को सफलतापूर्वक मॉडरेट किया गया और स्क्रीन को हिट किया गया।

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

बेशक, सभी उपयोगकर्ता स्क्रीन पर भेजे गए संदेश को अपनी आँखों से देखना चाहते थे। इसे संभव बनाने के लिए, हमें उस प्रश्न का उत्तर देना होगा जब प्रत्येक संदेश वहाँ दिखाई दे।

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

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

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

तकनीकी परियोजनाएं

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

जीविका ओपन सोर्स प्रोजेक्ट

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

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

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

PHP 7.4 में माइग्रेट करना

PHP के नए संस्करण प्रदर्शन सुधार से प्रसन्न हैं। पिछले दो बदलावों में (7.0 से 7.2 और 7.2 से 7.4 तक), हमारा विभाग जिम्मेदार था। आधिकारिक रिलीज से बहुत पहले

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

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

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

अनुरोधों का एकत्रीकरण करें

PHP अपडेट के साथ, प्रदर्शन के लिए हमारा संघर्ष समाप्त नहीं होता है। हमारे पास एक शक्तिशाली ढांचा है जो शुरुआत में बहुत काम करता है: आरंभीकरण से लेकर प्रत्येक अनुरोध के लिए आवश्यक विभिन्न जांचों तक।

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

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

फोटो अनुकूलन

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

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

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

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

जिस कार्य को हम हल करना चाहते थे, वह था इष्टतम प्रारूप (JPEG, WebP, PJPEG), आकार और छवि गुणवत्ता। सिद्धांत रूप में, वेबपी प्रारूप सबसे अच्छा होना चाहिए, लेकिन यह मक्खी पर रूपांतरण के मामले में सबसे महंगा है: यातायात को बचाने के बजाय, आपको अधिक फोटो कैश सर्वर खरीदने की आवश्यकता है। इसके साथ ही, हमने यह परीक्षण करने का निर्णय लिया कि इस क्षेत्र में CDN कैसे UX को बेहतर बनाने में मदद करेगा।

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

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

खुद की वीडियो स्ट्रीमिंग

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

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

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

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

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

अनुसंधान की शुरुआत से लेकर पूर्ण कार्यान्वयन तक, परियोजना को छह महीने से अधिक समय हो गया, लेकिन परिणामस्वरूप, हम बाहरी सेवाओं को छोड़ कर लागत को कम करने में सक्षम थे।

प्रदर्शन अनुकूलन

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

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

हम सम्मेलनों और बैठकों में अनुकूलन कार्य के दौरान प्राप्त ज्ञान को सक्रिय रूप से साझा करते हैं। हमारी परियोजनाओं और अध्ययनों के बारे में अधिक विवरण पाशा मुरज़कोव के लेख और रिपोर्ट में पाए जा सकते हैं:

पुराने और अप्रयुक्त कोड पर नियंत्रण

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

कार्य की उच्च गति बनाए रखने के लिए हम अपने कोड आधार को "स्वच्छ" रखने का प्रयास करते हैं:

स्वचालित रूप से उत्पाद प्रयोग के पूरा होने के बाद कोड को हटाने के लिए कार्य करें;
अनुप्रयोगों और ऑपरेटिंग सिस्टम के पुराने संस्करणों और उन में उपयोग की जाने वाली कोड शाखाओं की स्वचालित ट्रैकिंग;
अप्रयुक्त कोड के लिए स्वचालित रूप से खोज करने के लिए प्रस्तुत उपकरण।

आप हमारे परिणामों के बारे में अधिक जानकारी के लिए PHP PHP Meetup , जो इस शनिवार, 15 फरवरी को आयोजित किया जाएगा।

बेशक, ये सभी परियोजनाएं नहीं हैं जिनके बारे में मैं बात करना चाहता हूं। पिछले दो वर्षों में, हमने स्पैमर्स और स्नैपर के साथ संघर्ष किया है, PhpStorm के लिए हमारे प्लगइन को देखा, विभिन्न KV रिपॉजिटरी (और एयरोस्पाइक चुना) का परीक्षण किया, सम्मेलनों में और न केवल लेखों में बहुत कुछ साझा ज्ञान का उपयोग किया।

लेकिन अगर आप तय करते हैं कि हम केवल काम कर रहे हैं, तो ऐसा नहीं है। प्रत्येक टीम का अपना टीम बिल्डिंग बजट होता है। हमारे सहयोगियों ने एम्स्टर्डम, एडिनबर्ग, प्राग और अन्य शहरों का दौरा किया। और पिछले साल हमने क्रोएशिया में विभाग की एक आम बैठक आयोजित की:

और हम यह भी जानते हैं कि फोटोशॉप कैसे किया जाता है। लंदन और इनहो में कार्यालय में जाने

पर । हमने पहले ही बताया था, इसलिए हम इस लेख में विवरण पर ध्यान नहीं देंगे - बस दो-दो फोटो दिखाएंगे।

बड़ी फोटो

हायरिंग इवेंट हमारी टीम में शामिल होने का सबसे आसान और तेज़ तरीका है। हम 1 मार्च तक परीक्षण के उत्तर को स्वीकार करते हैं । फिर हम परिणामों का विश्लेषण करने और कार्यों से निपटने वालों को कॉल करने के लिए एक सप्ताह का समय लेंगे।

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

यदि आपके कोई प्रश्न हैं, तो बेझिझक उन्हें टिप्पणियों में पूछ सकते हैं या मुझे निजी संदेश भेज सकते हैं।

सौभाग्य

लंदन में एक दिन में पेश करें: इसे कैसे प्राप्त करें और आगे बढ़ने के बाद क्या करें