एक वास्तविक समय प्रणाली के रूप में वेब सेवा

दिसंबर की शुरुआत में, मेल पीटर्सबर्ग के साझेदारी के साथ, सेंट पीटर्सबर्ग में, ACM ICPC प्रोग्रामिंग विश्व चैम्पियनशिप का सेमीफाइनल आयोजित किया गया था। चैंपियनशिप के भाग के रूप में, मैं प्रतिभागियों से मिला और एक वेब सेवा को वास्तविक समय प्रणाली बनाने के बारे में बात की; और अब मैं अपनी रिपोर्ट Habré पर साझा करना चाहता हूं।

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

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

जब कोई उपयोगकर्ता कहीं क्लिक करता है, तो वह अपेक्षा करता है कि वह अपने क्लिक पर तुरंत प्रतिक्रिया प्राप्त करे। तत्काल क्या है? किसी व्यक्ति के लिए, एक आरामदायक देरी को 200 मिलीसेकंड के आदेश का प्रतिक्रिया समय माना जाता है, हालांकि वास्तव में मानव आंख लगभग 10 मिलीसेकंड के बीच अंतर करती है। एक वेब सेवा को 200 मिलीसेकंड से अधिक नहीं में उपयोगकर्ता कार्यों का जवाब देना चाहिए - कम बेहतर।

तो, एक आधुनिक वेब सेवा, वास्तव में, एक वास्तविक समय प्रणाली होनी चाहिए। इस आवश्यकता को पूरा करने के लिए, मैं Mail.Ru मेल के उदाहरण पर बताऊंगा।

अनुरोध का प्रसंस्करण समय क्या है

वेब सेवा के अनुरोध के लिए प्रसंस्करण समय में निम्नलिखित बातें शामिल हैं:

1 सबसे पहले एक DNS क्वेरी है। DNS क्वेरी, निश्चित रूप से, हमेशा नहीं होती है, क्योंकि क्लाइंट DNS रिज़ॉल्यूशन के परिणामों को थोड़ी देर के लिए कैश करता है। सिद्धांत रूप में, इसे लंबे समय तक कैश किया जा सकता है, लेकिन DNS रिकॉर्ड में TTL जैसी कोई चीज होती है। यदि यह छोटा है, तो ग्राहक को TTL क्षय के दौरान एक और DNS क्वेरी करनी होगी। यही समय है।

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

3 कनेक्शन के बाद, अनुरोध नेटवर्क पर भेजा जाता है। ब्राउज़र एक अनुरोध भेजता है, जो सर्वर पर संसाधित होता है।

4 तब ब्राउज़र सर्वर से एक प्रतिक्रिया प्राप्त करता है, HTML को एक सुंदर दृश्य में बदल देता है, और उसके बाद ही उपयोगकर्ता को दिखाता है।

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

चूंकि यह अमरता को गले लगाने के लिए असंभव है, इस लेख में मैं सर्वर पर प्रसंस्करण पर विचार करूंगा और बताऊंगा कि हम Mail.RR मेल में उच्च गति कैसे प्राप्त करते हैं।

सर्वर पर क्या होता है

सर्वर पर प्रसंस्करण में कई अनुक्रमिक क्रियाएं भी होती हैं।

वेब सर्वर चाहिए:

1 कनेक्शन स्वीकार करें;
2 पार्स अनुरोध;
3 हैंडलर के लिए अनुरोध पारित;
4 अनुरोध के सभी व्यापार तर्क को निष्पादित;
5 को हैंडलर से प्रतिक्रिया मिलती है;
6 क्लाइंट को जवाब देना।

फिर से, ये सभी क्रियाएं सख्ती से अनुक्रमिक हैं, और वे ऊपर वर्णित अन्य सभी कार्यों के साथ संक्षेप भी करते हैं।

आइए Mail.Ru मेल में एक संदेश पढ़ने के एक विशिष्ट उदाहरण को देखें, अनुरोध प्रसंस्करण के अंदर क्या हो रहा है और किस तरह का व्यावसायिक तर्क है।







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

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

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

सत्र सत्यापन

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

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

यह पता चला है कि आप SQL में स्टोर नहीं कर सकते हैं, केवल NoSQL भंडारण, केवल स्मृति में, केवल कट्टर। Mail.Ru में, हम अपने स्वयं के टारेंटूल डेटाबेस को इन-मेमोरी स्टोरेज के रूप में उपयोग करते हैं। यह केवल मेमोरी से पढ़ता है, मेमोरी से और डिस्क से लिखता है। रिकॉर्डिंग भी बहुत तेज़ है, क्योंकि केवल APPEND का उपयोग किया जाता है, कोई यादृच्छिक खोज नहीं है। तदनुसार, ज्यादातर मामलों में, टारेंटूल का उत्तर एक मिलीसेकंड के अंशों में आता है।

मेल भंडारण

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

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

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

पार्सिंग पत्र

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

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

फ़िशिंग

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

आंकड़े

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

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

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

निष्कर्ष

निष्कर्ष में - वेब सिस्टम के उन हिस्सों के डेवलपर्स के लिए कुछ निष्कर्ष जो ऑनलाइन काम करते हैं।

हमेशा मिलीसेकंड याद रखें। वे केवल सारांशित हैं, वे कभी भी घटाए नहीं जाते, दुर्भाग्य से। जहां भी आपको किसी तरह की देरी होती है, उसे जोड़ा जाता है।

यदि आप इसका उपयोग करते हैं तो तृतीय-पक्ष कोड प्रदर्शन के बारे में सुनिश्चित करें।

सब कुछ और सब कुछ टाइमआउट के साथ सर्कल करें।

खैर, डेटाबेस का जिक्र करते हुए, कुछ तृतीय-पक्ष रिपॉजिटरी या कुछ और, यह मत सोचो कि अंदर जादू है और सब कुछ तुरंत किया जाता है। वास्तव में, एक ही कोड के अंदर, जो अच्छी तरह से उप-प्रकार हो सकता है।

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