Yandex.Mail और Nginx टीमों का संयुक्त प्रयोग: क्या SPDY वास्तव में इंटरनेट को गति देगा?

हम Yandex.Mail पर, Nginx टीम के साथ मिलकर, एक अध्ययन में "" को एक जीवित उदाहरण में अंजाम देने के लिए एक अध्ययन किया, जिसमें बताया गया कि कैसे और कितना SPDY इंटरनेट को गति देता है।



बेशक, आप SPDY के बारे में ही जानते हैं। 2011 में, कई Google डेवलपर्स ने सामान्य HTTP को बदलने के लिए डिज़ाइन किए गए एक नए प्रोटोकॉल का एक मसौदा प्रकाशित किया। इसके मुख्य अंतर थे मल्टीप्लेक्सिंग प्रतिक्रियाएं, हेडर कंप्रेस करना और ट्रैफ़िक को प्राथमिकता देना। पहले कुछ संस्करण पूरी तरह से सफल नहीं थे, लेकिन 2012 तक विनिर्देश अच्छी तरह से स्थापित हो गया था, पहला वैकल्पिक (गैर-Google) कार्यान्वयन दिखाई दिया, ब्राउज़रों में समर्थन का हिस्सा 80% तक पहुंच गया, SPDY के लिए समर्थन के साथ nginx का एक स्थिर संस्करण सामने आया।







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



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

स्पीडी। अंदर का नजारा

SPDY प्रोटोकॉल के बारे में बात करना काफी जटिल और कठिन है। आइए स्पष्ट रूप से वर्णन करने का प्रयास करें कि यह कैसे काम करता है।



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



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







उसके बाद, सर्वर इन फ़ाइलों को क्रमिक रूप से देना शुरू करता है।

HTTPS

कनेक्ट + टीएलएस-हैंडशेक	कनेक्ट + टीएलएस-हैंडशेक	कनेक्ट + टीएलएस-हैंडशेक
> Gb /bootstrap.css > ... <HTTP / 1.1 200 ठीक है <... <शरीर {मार्जिन: 0 ;;	> GET /jquery.min.js > ... <HTTP / 1.1 200 ठीक है <... <(फ़ंक्शन (विंडो, अपरिभाषित)) <...	> GET / logo.png > ... <HTTP / 1.1 200 ठीक है <... <[डेटा] <...

HTTPS + SPDY

कनेक्ट + टीएलएस-हैंडशेक
> Gb /bootstrap.css > GET /jquery.js > Glog /logo.png <[bootstrap.css सामग्री] <... <[jquery.js सामग्री] <... <[logo.png सामग्री]

पहले बूट को गति दें

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



हम रूस और विदेशों में मॉस्को और सीडीएन में स्थित लगभग 200 सर्वरों के उपयोगकर्ताओं को यह स्टैटिक्स वितरित करते हैं। हम Nginx को सर्वर के रूप में उपयोग करते हैं, क्योंकि हम मानते हैं कि यह मौजूदा वेब सर्वर का सबसे तेज़ और सबसे विश्वसनीय है जो स्टैटिक्स वितरित कर सकता है। पिछले साल, Nginx टीम ने मॉड्यूल के रूप में SPDY संस्करण 2 प्रोटोकॉल के अपने कार्यान्वयन की घोषणा की। और हमने 2013 की शुरुआत में Nginx और इस मॉड्यूल का उपयोग करके स्टैटिक्स वितरित करने का प्रयास करना शुरू कर दिया।

चल रहे अनुकूलन

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



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

हमने लोड समय कैसे मापा

सबसे पहले, हमने अपने परीक्षण मशीनों पर मापने का फैसला किया कि हम विन्यास में केवल SPDY को सक्षम करके कितना तेजी लाएंगे। हमने उपयोगकर्ताओं के लिए दुर्गम एक भौतिक मशीन पर स्टैटिक्स बिछाया, जो उबंटू 12.04 चल रहा था। एक टाइपराइटर पर 12 कोर और 20GB रैम थी। सभी स्थैतिक को रैम में एक रैम डिस्क में रखा गया था।



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



उनमें से, 10% को सभी के बीच बेतरतीब ढंग से चुना गया था और उन्हें दो समूहों में विभाजित किया गया था: पहला समूह एसपीडीवाई के माध्यम से स्थिर दिया गया था, और दूसरा समूह नियंत्रण था।



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

मैट्रिक्स

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



डाउनलोड गति के अलावा, हमारे लिए एक महत्वपूर्ण पहलू स्थिर डाउनलोड की संख्या है। हम ग्राहकों पर दो चीजों की जाँच करते हैं:



1. क्या आपने एक स्थिर फ़ाइल प्राप्त करने का प्रबंधन किया है ? उदाहरण के लिए, सर्वर ने उत्तर दिया कि ऐसी कोई फ़ाइल नहीं थी। प्रत्येक ऐसे उतराई के तथ्य को हम सर्वर पर भी भेजते हैं और उनकी संख्या का ग्राफ बनाते हैं।



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

माप के परिणाम

आंकड़ों के आधार पर हमने स्टेटिक्स, माध्यिका के औसत लोड समय और साथ ही साथ प्रतिशत 80% की गणना की। दुर्भाग्य से, हमारे उपकरणों के त्वरण ने सांख्यिकीय त्रुटि को दूर नहीं किया।







औसत लोड समय 0.6% घट गया। यही है, Google के सभी आश्वासनों के बावजूद, SPDY इस तरह से उन पागल 50-50% द्वारा किसी भी साइट को लेने और गति देने में सक्षम नहीं है।

ओपेरा 12.16 और सामग्री-लंबाई

हमने mail.yandex.ru पर SPDY / 2 को सक्षम करने का प्रयास किया। चालू करने के बाद, हमें लॉग में बहुत सारी त्रुटियां मिलीं और हमें इसे बंद करना पड़ा। ओपेरा में एक अप्रिय बग है, जो, चूंकि इसका समर्थन पहले ही बंद हो चुका है, इसलिए तय होने की संभावना नहीं है। यह इस तथ्य में शामिल है कि ओपेरा POST अनुरोध भेजते समय अमान्य सामग्री-लंबाई शीर्ष लेख भेजता है। समस्या यहाँ वर्णित है: trac.nginx.org/nginx/ticket/337



यदि आपके पास पुराने ओपेरा (12. *) वाले कई आगंतुक हैं और POST अनुरोधों का उपयोग किया जाता है, तो हम अनुशंसा नहीं करते हैं कि आप SPDY को सक्षम करें।

UPD: SPDY डेवलपर टिप्पणियों में सुझाव देता है कि संस्करण 1.5.10 से शुरू होकर, nginx में पहले से ही प्रोटोकॉल का तीसरा संस्करण है, और इसलिए पुराने ओपेरा अब SPDY का उपयोग नहीं करेगा जब इसके साथ काम करना होगा। इसलिए, ओपेरा की बग अप्रासंगिक होगी।

निष्कर्ष

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



हालांकि, SPDY में हमने अपने लिए अप्रत्याशित लाभ पाया। इस तथ्य के कारण कि कई ग्राहकों ने प्रत्येक फ़ाइल के लिए कनेक्शन बनाना बंद कर दिया, ये कनेक्शन काफ़ी कम हो गए, जिसका अर्थ है कि हमारे प्रोसेसर कम लोड करने लगे। वह है, नहीं, लेकिन एक बचत है।



इस तरह से SPDY का समावेश हमारे सर्वरों पर खुले कनेक्टिविटी ग्राफ पर दिखता है।







हमें स्टैटिक्स लोडिंग त्रुटियों की संख्या में अंतर नहीं मिला। इसका मतलब है कि Nginx में SPDY को शामिल करने से ब्राउज़र में कोई समस्या पैदा नहीं होती है, यहां तक ​​कि जहां यह समर्थित नहीं है।



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



परिणामस्वरूप, हमने सभी yandex.st पर SPDY को शामिल किया। हालाँकि इसने हमें 100500% का त्वरण नहीं दिया, लेकिन इसने CPU के कम लोड के कारण कुछ बिजली बचाई :)



स्पीडअप की कमी का एक और कारण है कि नग्नेक्स खुद एक अविश्वसनीय रूप से तेज़ सर्वर है। प्रारंभ में, SPDY को Apache सर्वर के लिए एक मॉड्यूल के रूप में लागू किया गया था, और जैसा कि आप जानते हैं, कनेक्शन को बनाए रखने के लिए बहुत सारे संसाधनों की आवश्यकता होती है। इसलिए, अपाचे में कनेक्टिविटी की बचत इसके प्रदर्शन में ध्यान देने योग्य लाभ देती है। Nginx में 10,000 निष्क्रिय HTTP रखने-जीवित कनेक्शन (स्रोत - nginx.org/ru ) को बनाए रखने के लिए लगभग 2.5M मेमोरी लेता है ।



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