गति के लिए एक व्यवस्थित दृष्टिकोण: सामने के छोर पर ऑनलाइन माप

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

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



यह सामग्री पवित्रजेएस सम्मेलन में एंड्री के भाषण पर आधारित है। कटौती के तहत - और वीडियो, और रिपोर्ट का एक पाठ संस्करण।

ऑनलाइन माप पर इस रिपोर्ट के अलावा, ऑफ़लाइन मापों पर अलेक्सी कलमाकोव ( यांडेक्स से भी) की एक रिपोर्ट है , उनके मामले में कोई पाठ संस्करण नहीं है, लेकिन एक वीडियो उपलब्ध है।

Yandex खोज परिणामों में उपयोगकर्ता के प्रश्नों के उत्तर के कई अलग-अलग ब्लॉक होते हैं। 50 से अधिक लोग कंपनी में उन पर काम करते हैं, और इसलिए कि जारी करने की दर में गिरावट नहीं होती है, हम लगातार विकास की देखभाल करते हैं।



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

इस प्रश्न का उत्तर देने के लिए, मैं दो कहानियाँ सुनाऊँगा।

जारी करने पर एक विशिष्ट वेब फ़ॉन्ट की शुरूआत का इतिहास

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



उपयोगकर्ताओं ने बाद में पृष्ठ के साथ बातचीत करना शुरू किया। क्लिक किए गए पृष्ठों की संख्या में लगभग आधा प्रतिशत की कमी हुई। सेवा पर उपस्थिति का समय कम हो गया था और अनुपस्थिति का समय बढ़ा दिया गया था।



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

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

एलएस कैशिंग इतिहास

यह कहानी इस तथ्य से संबंधित है कि हम पृष्ठ में बहुत सारी स्थिर सामग्री को इनलाइन करते हैं।



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

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

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



औसत HTML डिलीवरी समय (अनुकूलन विकास के समय प्रमुख मीट्रिक) में 12% की वृद्धि हुई, जो बहुत कुछ है। लेकिन उसी समय, जब तक हेडर तैयार नहीं किया गया था, तब तक सामग्री के पार्सिंग शुरू होने से पहले और जावास्क्रिप्ट शुरू होने से पहले। पहले क्लिक के समय को भी कम कर दिया। इस पर प्रतिशत छोटा है - 0.6, लेकिन यदि आप पैमाने को याद करते हैं ...



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

निम्नलिखित निष्कर्ष इससे लिए जा सकते हैं:

सबसे पहले, गति वास्तव में व्यापार और व्यापार मैट्रिक्स को प्रभावित करती है।

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



एक बार, ऐश ने हमें पहले शूट करने के लिए मृत पापी से सिखाया, फिर सोचने के लिए या बिल्कुल नहीं सोचने के लिए। गति में, आपको ऐसा नहीं करना होगा।

और तीसरा बिंदु: माप उपयोगकर्ता अनुभव को प्रतिबिंबित करना चाहिए। उदाहरण के लिए, HTML आकार और डिलीवरी का समय खराब गति का मैट्रिक्स है क्योंकि उपयोगकर्ता devTools के साथ नहीं बैठता है और कम देरी के साथ सेवा का चयन नहीं करता है। लेकिन क्या मैट्रिक्स अच्छे और सही हैं - हम आगे बताएंगे।

क्या और कैसे मापें?

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



यदि TTFCP (पहली सामग्री के लिए समय) और TTFMP (पहली सार्थक पेंट करने का समय) उस समय को इंगित करता है जब तक कि सामग्री के पहले प्रतिपादन और महत्वपूर्ण सामग्री के प्रतिपादन से पहले का समय नहीं हो जाता है, तो तीसरा है फ्रेमवर्क शुरू होने से पहले का समय, यह समझाने लायक है।

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

और अंतिम, चौथा मीट्रिक, पहली अन्तरक्रियाशीलता तक का समय, आमतौर पर संवादात्मक (टीटीआई) के रूप में संदर्भित किया जाता है।

HTML आकार या डिलीवरी समय के विपरीत ये मीट्रिक उपयोगकर्ता अनुभव के करीब हैं।

Firstcontentfull पेंट करने का समय

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



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

तो हम घटनाओं की एक सरणी मिलता है, फर्स्टकंटफुल पेंट को फ़िल्टर करते हैं और एक निश्चित आईडी के साथ भेजते हैं।

पहली सार्थक पेंट करने का समय

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

इस मीट्रिक को मापने के लिए यैंडेक्स में बैसाखी के दो स्कूल हैं: RequestAnimationFrame का उपयोग करना और इंटरसेप्शनऑब्जर्वर के साथ माप करना।

RequestAnimationFrame में, एक अंतराल का उपयोग करके रेंडरिंग को मापा जाता है।



मान लीजिए कि कुछ महत्वपूर्ण सामग्री है। यहाँ कक्षा मुख्य-सामग्री के साथ एक div है। इसके सामने एक स्क्रिप्ट रखी जाती है, जहाँ RequestAnimationFrame को दो बार कहा जाता है।

पहली कॉल के कॉलबैक में, अंतराल की निचली सीमा लिखें। दूसरे के कॉलबैक में - शीर्ष। यह फ्रेम संरचना के कारण है जो ब्राउज़र प्रदान करता है।



पहले जावास्क्रिप्ट का निष्पादन है, फिर शैलियों का विश्लेषण, फिर लेआउट, प्रतिपादन और रचना की गणना।

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



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

InterceptionObserver

एक ही सामग्री के साथ हमारी दूसरी बैसाखी अलग तरीके से काम करती है। इस बार स्क्रिप्ट को नीचे रखा गया है। इसमें हम InterceptionObserver बनाते हैं और domNode की सदस्यता लेते हैं।



हम अतिरिक्त मापदंडों को पास नहीं करते हैं, इसलिए हम व्यूपोर्ट के साथ इसके चौराहे को मापते हैं। यह समय प्रतिपादन के सटीक समय के रूप में दर्ज किया गया है।



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

इन दो तरीकों में से, RequestAnimationFrame का उपयोग करना अभी भी बेहतर है: इसका समर्थन व्यापक है, और व्यवहार में यह हमारे द्वारा बेहतर परीक्षण किया जाता है।

जे एस ined

एक ऐसे ढाँचे की कल्पना करें, जिसमें "init" घटना हो, जिसे आप सब्सक्राइब कर सकते हैं, लेकिन याद रखें कि व्यवहार में JS Inited एक सरल और जटिल मीट्रिक है।



सरल - क्योंकि आपको केवल उस क्षण को खोजने की आवश्यकता है जब फ्रेमवर्क ने घटनाओं की व्यवस्था समाप्त कर दी है। जटिल - क्योंकि आपको प्रत्येक फ्रेम के लिए अपने दम पर इस बिंदु को देखना होगा।

इंटरएक्टिव करने का समय

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

लंबे कार्यों की अवधारणा और लॉन्ग टास्क एपीआई इसे मापने में मदद करता है।

सबसे पहले लंबे कार्यों के बारे में।



तीर द्वारा इंगित किए गए छोटे कार्यों के बीच, ब्राउज़र आसानी से उपयोगकर्ता घटना के प्रसंस्करण को रोक सकता है, उदाहरण के लिए, इनपुट, क्योंकि इसकी उच्च प्राथमिकता है। लेकिन लाल तीर द्वारा इंगित लंबे कार्यों के साथ, यह काम नहीं करेगा।

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

जावास्क्रिप्ट के अंदर इस अंतराल को कैसे मापें?



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



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

इस मीट्रिक पर मूल कार्य में, 5 सेकंड को एक स्थिर के रूप में लिया गया था, लेकिन विकल्प किसी भी तरह से पुष्टि नहीं किया गया था। यह 3 सेकंड के लिए पर्याप्त निकला। यदि 3 सेकंड बीत जाते हैं, तो हम पहली अन्तरक्रियाशीलता तक का समय गिनते हैं; यदि नहीं, तो हम इस स्थिरांक को फिर से सेट करते हैं और जाँचते हैं।

डेटा को कैसे प्रोसेस करें?

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



हम बैकेंड पर एक विशेष मीट्रिक के डेटा को एक विशेष पेन में स्थानांतरित करते हैं और इसे रिपॉजिटरी में इकट्ठा करते हैं।



यहां, डेटा एकत्रीकरण को पारंपरिक रूप से SQL क्वेरी के रूप में नामित किया गया है। यहाँ मुख्य एकत्रीकरण हैं जिन्हें हम आमतौर पर गति मैट्रिक्स के अनुसार मानते हैं: अंकगणितीय माध्य और प्रतिशतक समूह (50 वां, 75 वां, 95 वां, 99 वां)।



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



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

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

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



इसके अलावा, हम माध्यिका पर विचार करते हैं (यदि हम इसे समय मैट्रिक्स में संलग्न करते हैं, तो माध्य उस समय का एक संकेतक है जिस पर 50% अनुरोध फिट होते हैं) और 75 वाँ प्रतिशत। 75% अनुरोध इस समय फिट हैं, हम इसे समग्र गति के अनुमान के रूप में लेते हैं। लंबी धीमी पूंछ को मापने के लिए 95 वें और 99 वें प्रतिशतक को माना जाता है। ये बहुत बड़ी संख्या में हैं। 95 वें सबसे धीमी अनुरोध के रूप में माना जाता है। 99 वाँ प्रतिशत असामान्य है।

अधिकतम गिनने का कोई मतलब नहीं है। यह पागलपन का तरीका है। अधिकतम गणना करने के बाद, यह पता चल सकता है कि उपयोगकर्ता 20 साल से पेज लोड होने की प्रतीक्षा कर रहा है।

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



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

हमें लगातार गति के ग्राफ़ की निगरानी करनी होगी, और हमने रोबोट को यह कार्य सौंपा।

निगरानी

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

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



यहाँ एक ग्राफ का उदाहरण दिया गया है जहाँ संरेखण हुआ और रोबोट ने इस घटना को दर्ज किया। उन्होंने इस क्षण को कई अन्य संकोचों से कैसे अलग किया? इसे समझने के लिए, हम अतिरिक्त डेटा लगाते हैं।



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



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

गति के लिए सुविधाओं की जाँच करना

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



हम उपयोगकर्ताओं को नियंत्रण और प्रयोगात्मक समूहों में विभाजित करते हैं। प्रत्येक स्लॉट की रीडिंग अलग-अलग एकत्रित और एकत्रित की जाती है।



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



इसे "MW" के रूप में नामित किया गया है क्योंकि मान-व्हिटनी परीक्षण का उपयोग गणना में किया जाता है। इसकी मदद से, तथाकथित "शुद्धता का प्रतिशत" की गणना की जाती है। इस सूचक में एक दहलीज है, जिसके बाद हम डेल्टा को सही मानते हैं। यहां इसे 99.9% पर सेट किया गया है।

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

इसे स्वयं कैसे करें?

आप दो तरीकों से गति माप लागू कर सकते हैं। पहला यह है कि सब कुछ आप ही करें।



क्लाइंट से डेटा प्राप्त करने के लिए एक हैंडल, एक बैकएंड, जो यह सब एक डेटाबेस, MongoDB, PostgreSQL, MySQL, किसी भी DBMS (वे बॉक्स से बाहर एकत्रीकरण) में डालते हैं, साथ ही कई खुले स्रोत समाधानों में से एक - रेखांकन आकर्षित करने और निगरानी की व्यवस्था करने के लिए।

दूसरा उपाय Yandex Metric या Google Analytics एनालिटिक्स सिस्टम का उपयोग करना है। यैंडेक्स मेट्रिक्स के उदाहरण पर, यह ऐसा दिखता है।



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

निष्कर्ष

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



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

अंत में घोषणा। यदि आपको होलीजेएस 2018 पाइटर के साथ यह बात पसंद आई है, तो आप शायद आगामी होल्जेएस 2018 मॉस्को में रुचि लेंगे , जो 24-25 नवंबर को आयोजित किया जाएगा। वहां आप न केवल कई अन्य जेएस-रिपोर्ट देख सकते हैं , बल्कि रिपोर्ट के बाद चर्चा क्षेत्र में किसी भी वक्ता से पूछ सकते हैं। और कल, 1 नवंबर से, टिकट की कीमतें फाइनल हो जाएंगी, इसलिए आज उन्हें छूट पर खरीदने का आखिरी मौका है!