उच्च प्रदर्शन Google Chrome

Google Chrome का इतिहास और कोने।

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

"यह इतना अच्छा था कि इसने मुझे अपना मन बदल दिया .." - एरिक श्मिट, शुरू में Google क्रोम के विचार को स्वीकार करने के लिए तैयार नहीं थे ।

हाँ, वह कर सकता था! आज, Google Chrome सबसे लोकप्रिय ब्राउज़रों ( 35% बाजार हिस्सेदारी, स्टेटकाउंटर संकेतक) में से एक है और विंडोज, लिनक्स, ओएस एक्स, क्रोम ओएस, एंड्रॉइड और आईओएस प्लेटफार्मों पर उपलब्ध है। निस्संदेह, इसके फायदे और व्यापक कार्यक्षमता ने उपयोगकर्ताओं के दिलों में एक प्रतिक्रिया पाई, जिससे अन्य ब्राउज़रों को कई अद्भुत विचार मिले।

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

• गति : सबसे तेज ब्राउज़र बनाते हैं
• सुरक्षा : उपयोगकर्ता को सबसे सुरक्षित कार्य वातावरण प्रदान करता है
• स्थिरता : वेब अनुप्रयोगों के लिए एक लचीला और स्थिर मंच प्रदान करते हैं
• सादगी : एक सरल इंटरफ़ेस के पीछे परिष्कृत तकनीक।

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

प्रदर्शन की बहुमुखी प्रतिभा।

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

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

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

Chrome, पृष्ठों को प्रदर्शित करने के लिए WebKit का उपयोग करता है, एक तेज़, खुला स्रोत और मानक-अनुरूप इंजन। JS चलाने के लिए, Chrome अपना स्वयं का उपयोग करता है, बहुत अच्छी तरह से अनुकूलित V8 जावास्क्रिप्ट इंजन, जो संयोगवश, एक ओपन सोर्स प्रोजेक्ट है, और उसने कई अन्य लोकप्रिय परियोजनाओं में अपना आवेदन पाया है - उदाहरण के लिए, node.js. हालांकि, वी 8 स्क्रिप्ट के निष्पादन को अनुकूलित करना, या वेब किट के साथ पृष्ठों को संसाधित करना और प्रदर्शित करना इतना महत्वपूर्ण नहीं है जब ब्राउज़र पेज बनाने के लिए आवश्यक संसाधनों की प्रतीक्षा कर रहा हो।

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

आधुनिक वेब एप्लिकेशन क्या है?

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

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

• "वजन" - 1280 KB
• 88 संसाधनों से मिलकर बनता है (चित्र, css, js)
• 30 से अधिक तृतीय-पक्ष साइटों के डेटा का उपयोग करता है।

आइए इसे और अधिक विस्तार से देखें। औसतन 1 एमबी से अधिक वजन, 88 संसाधन होते हैं, और 30 अलग-अलग स्वामित्व और तीसरे पक्ष के सर्वर से इकट्ठा होते हैं। ध्यान दें कि इनमें से प्रत्येक संकेतक पिछले कुछ वर्षों में लगातार बढ़ रहा है , और यह अनुमान लगाने का कोई कारण नहीं है कि यह वृद्धि बंद हो जाएगी। हम अधिक से अधिक भारी संख्या में निर्माण कर रहे हैं और बढ़ती संख्या में वेब अनुप्रयोगों की मांग कर रहे हैं, और इसका कोई अंत नहीं है।

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

विशिष्ट अनुरोध जीवन

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



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

साइट का पता और अनुरोधित संसाधन का मार्ग होने के कारण, Chrome पहले यह देखने के लिए जांच करता है कि क्या इस साइट के लिए खुले कनेक्शन हैं जिनका उपयोग फिर से किया जा सकता है - सॉकेट्स को {scheme, host, port} द्वारा समूहीकृत किया जाता है। यदि आप प्रॉक्सी के माध्यम से इंटरनेट एक्सेस करते हैं, या प्रॉक्सी ऑटो-कॉन्फिग (पीएसी) स्क्रिप्ट स्थापित की है, तो यह देखने के लिए क्रोम चेक करता है कि क्या आपके पास उचित प्रॉक्सी के माध्यम से सही कनेक्शन है। PAC स्क्रिप्ट आपको URL या अन्य कॉन्फ़िगरेशन नियमों के आधार पर कई प्रॉक्सी निर्दिष्ट करने की अनुमति देती है, और उनमें से प्रत्येक के पास कनेक्शन का अपना सेट हो सकता है। और अंत में, यदि उपरोक्त शर्तों में से कोई भी फिट नहीं होता है, तो हमें जिस पते की आवश्यकता है उसके लिए आईपी पता प्राप्त करने की बारी आई - DNS लुकअप

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

आईपी ​​प्राप्त करने के बाद, क्रोम दूरस्थ सर्वर पर एक नया टीसीपी कनेक्शन स्थापित कर सकता है, जिसका अर्थ है कि हमें तथाकथित थ्री-वे हैंडशेक (तीन बार ग्रीटिंग): SYN> SYN-ACK> ACK करना चाहिए। यह हैलो एक्सचेंज प्रत्येक नए टीसीपी कनेक्शन के लिए अनुरोध-प्रतिक्रिया विलंब जोड़ता है - कोई अपवाद नहीं । मार्ग के विकल्प को देखते हुए, क्लाइंट और सर्वर के बीच की दूरी के आधार पर, यह हम में कई सौ और हजारों मिलीसेकंड ले सकता है। ध्यान दें कि यह सब रोबोट वेब एप्लिकेशन डेटा के एक बाइट से पहले ही निष्पादित हो जाता है!

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

अंत में, सभी प्रक्रियाओं के बाद, क्रोम अंततः HTTP अनुरोध (ऊपर दिए गए आरेख में requestStart) भेजने में सक्षम है। अनुरोध प्राप्त करने के बाद, सर्वर इसे संसाधित करना शुरू कर देता है, और क्लाइंट को एक प्रतिक्रिया भेजता है। इसके लिए कम से कम एक चक्र की आवश्यकता होगी, साथ ही सर्वर पर अनुरोध को संसाधित करने में लगने वाला समय। और इसलिए, हम अंत में जवाब मिला। हाँ, यदि यह उत्तर HTTP पुनर्निर्देशित नहीं है! इस मामले में, हमें एक बार फिर पूरी प्रक्रिया को एक पूरे के रूप में दोहराना होगा। क्या आपके पृष्ठों पर आपको पुनर्निर्देशित करने की आवश्यकता नहीं है? शायद उनके पास लौटने के लायक है, और अपना मन बदलो।

क्या आपने इन सभी देरी पर विचार किया? समस्या का वर्णन करने के लिए, आइए एक विशिष्ट ब्रॉडबैंड कनेक्शन के सबसे खराब स्थिति को देखते हैं: स्थानीय कैश खो जाता है, इसके बाद अपेक्षाकृत तेज़ DNS लुकअप (50ms), टीसीपी ग्रीटिंग, एसएसएल बातचीत, और अपेक्षाकृत त्वरित (100ms) सर्वर प्रतिक्रिया, अनुरोध और प्रतिक्रिया वितरण के लिए 80ms (औसत) महाद्वीपीय अमेरिका साइकिल समय):

• डीएनएस के लिए 50 एमएस
• DNS अभिवादन के लिए 80 एमएस (एक चक्र)
• एसएसएल अभिवादन के लिए 160 एमएस (दो चक्र)
• सर्वर से प्रति अनुरोध 40ms
• सर्वर पर अनुरोध को संसाधित करने के लिए 100 एमएस
• सर्वर से 40 एमएस प्रतिक्रिया

कुल में, यह एक अनुरोध के लिए 470 एमएस है, जो उस समय की तुलना में सर्वर के साथ कनेक्शन स्थापित करने के लिए 80% से अधिक समय की लागत की ओर जाता है जब सर्वर को अनुरोध को संसाधित करने की आवश्यकता होती है । वास्तव में, यहां तक ​​कि 470 मिलीसेकंड एक आशावादी अनुमान हो सकता है:

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

उपवास का पर्याप्त अर्थ क्या है?

DNS, बधाई और संदेश के लिए नेटवर्क खर्च - यह वही है जो पिछले मामलों में कुल समय पर हावी है - सर्वर प्रतिक्रिया को कुल प्रतीक्षा का केवल 20% की आवश्यकता होगी! लेकिन, बड़े और बड़े, इन देरी से बात करते हैं ? यदि आप इसे पढ़ते हैं, तो आप शायद पहले से ही जवाब जानते हैं - हाँ, और एक बहुत बड़ा।

हाल के उपयोगकर्ता अध्ययन ऑनलाइन और ऑफलाइन दोनों अनुप्रयोगों में किसी भी इंटरफ़ेस से उपयोगकर्ताओं को क्या उम्मीद करते हैं, निम्नलिखित चित्र चित्रित करते हैं:

विलंब	उपयोगकर्ता की प्रतिक्रिया
0-100ms।	तुरंत
100-300 मि।	मामूली लेकिन ध्यान देने योग्य देरी
300-1000ms।	प्रसंस्करण में अनुरोध
1s से अधिक।	उपयोगकर्ता का ध्यान किसी अन्य संदर्भ पर स्विच करना
10 से अधिक।	मैं बाद में वापस आ जाऊंगा

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

और इसलिए, हमारे पास लगभग 250ms का एक इष्टतम विलंब सूचक है, लेकिन, जैसा कि हमने ऊपर देखा, DNS क्वेरीज़, टीसीपी और एसएसएल कनेक्शन का एक संयोजन और क्वेरी डिलीवरी 370ms तक होती है। हमने 50% से अधिक की सीमा पार कर ली है, और हमने अभी भी सर्वर पर अनुरोध के प्रसंस्करण समय को ध्यान में नहीं रखा है!

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

हमने समस्या पर चर्चा की, यह कार्यान्वयन विवरण पर आगे बढ़ने का समय है।

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