BITCOIN

प्रदर्शन महत्वपूर्ण: प्रदर्शन स्वास्थ्य और प्राथमिकता का मार्गदर्शन करने के लिए एक एकीकृत स्कोरिंग प्रणाली

Tl;dr: निम्नलिखित पोस्ट में बताया गया है कि हम कॉइनबेस पर उत्पादों और क्रॉस-फंक्शनल टीमों में क्लाइंट के प्रदर्शन को कैसे मापते हैं।

लियोनार्डो ज़िज़ामिया द्वारा, वरिष्ठ स्टाफ सॉफ्टवेयर इंजीनियर

2018 के बाद से बहुत कुछ बदल गया है जब कॉइनबेस वेब टीम में केवल कुछ इंजीनियर शामिल थे। उस समय, एक ही प्लेटफॉर्म पर एक छोटे समूह के साथ अपने उत्पाद को तेज बनाने पर काम करते हुए, हम पहले से मौजूद ओपन सोर्स टूल्स

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

Google वेब वाइटल का विस्तार

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

महत्वपूर्ण मेट्रिक्स थ्रेसहोल्ड द्वारा विभेदित हैं जो प्रत्येक प्रदर्शन माप को “

अच्छा के रूप में वर्गीकृत करते हैं “, “सुधार की जरूरत“, या “

गरीब “।

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

क्लाइंट उत्पाद के समग्र प्रदर्शन को वर्गीकृत करने के लिए, कॉइनबेस सर्वोत्तम प्रथाओं का पालन करता है और उस पृष्ठ या स्क्रीन के लिए सभी मापों के 85 वें प्रतिशतक मूल्य का उपयोग करता है। दूसरे शब्दों में, यदि कम से कम

माप का 85%

एक साइट पर मिलते हैं “

अच्छा

” सीमा, साइट को उस मीट्रिक के लिए “अच्छा” प्रदर्शन होने के रूप में वर्गीकृत किया गया है। यह मीट्रिक Google वेब वाइटल मानक

से 10 अंक अधिक है , हमें संभावित प्रतिगमन को ठीक करने के लिए पर्याप्त बैंडविड्थ दे रहा है।

इन मेट्रिक्स को कैप्चर करने के लिए हम जिस प्राथमिक टूल का उपयोग करते हैं, वह है Perfume.js पुस्तकालय,

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

। एनटीबीटी उपयोगकर्ता द्वारा पेज ए से पेज बी पर नेविगेट करने के बाद 2 सेकंड की विंडो के दौरान प्रोसेसिंग कोड से एप्लिकेशन को ब्लॉक किए जाने की मात्रा को मापता है। एनटीबीटी मीट्रिक 2s विंडो के भीतर सभी लंबे कार्यों के लिए ब्लॉकिंग समय का योग है। इस विधि को लागू किया जाता है।

नीचे दी गई छवि है

कॉइनबेस में एनटीबीटी प्रदर्शन चिह्न का एक उदाहरण। com

एक क्लाइंट इंजीनियर को लंबे कार्य को ट्रैक करने और सुधार करने में मदद करता है जवाबदेही

पृष्ठों के बीच नेविगेट करते समय।

)

    Perfume.js का उपयोग करने का एक और तरीका यह है कि हम नेविगेटर एपीआई के साथ सभी मीट्रिक को समृद्ध करने में सक्षम हैं I एनएफओ, लो-एंड और हाई-एंड अनुभवों के बीच अंतर करने के लिए।

    वेब वाइटल को अपनाने और विस्तारित करने के बाद, हमारे लिए अगला कदम इस ज्ञान को हमारे स्टैक में पुन: उपयोग करना था।

कॉइनबेस प्रदर्शन महत्वपूर्ण

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

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

प्रतिक्रियाशील मूल निवासी विटल्स बनाना होते रिएक्ट नेटिव के प्रदर्शन का मूल्यांकन करते समय हमने

ऐप रेंडर कम्प्लीट के प्रारंभिक विटल्स विकसित किए और

नेविगेशन कुल अवरोधन समय होते

ऐप रेंडर पूर्ण (एआरसी): एप्लिकेशन को शुरू करने से लेकर संकेतक लोड किए बिना उपयोगकर्ता को सामग्री को पूरी तरह से प्रस्तुत करने में लगने वाले समय को मापता है। 5s की गुड थ्रेशोल्ड के मार्गदर्शन पर आधारित है एंड्रॉयड समुदाय आधिकारिक शोध।

नेविगेशन टोटल ब्लॉकिंग टाइम (NTBT): उपाय उपयोगकर्ता द्वारा स्क्रीन A से स्क्रीन B पर नेविगेट करने के बाद 2s विंडो के दौरान एप्लिकेशन को प्रोसेसिंग कोड से ब्लॉक किया जा सकता है।

एनटीबीटी के लिए हमने मोबाइल के लिए एक सीमा निर्धारित करने के लिए वेब वाइटल से कुल अवरोधन समय के आसपास मौजूदा ज्ञान का उपयोग किया। यह देखते हुए कि वेब पर एक अच्छा टीबीटी 200ms है और हम मोबाइल में अधिक समय लगने की उम्मीद करते हैं, हमने वेब से मानक को दोगुना कर दिया और मोबाइल के लिए 400ms पर पहुंच गया।

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

)

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

वेब के अनुभव के समान, कॉइनबेस ने एक इन-हाउस रिएक्ट नेटिव बनाया के लक्ष्य के साथ, इस प्रदर्शन को मापने के लिए कोर वाइटल्स लाइब्रेरी

ओपन सोर्सिंग

आने वाली तिमाहियों में समुदाय के लिए हमारी खोज।

बैकएंड विटल्स बनाना

जैसा कि हमने

के साथ किया था वेब और रिएक्टिव नेटिव विटल्स, हमने बैकएंड सेवाओं सहित वाइटल मानक को बढ़ाया है। ग्राफ़क्यूएल और बैकएंड सेवाएं।

हमने पहली बार दो मेट्रिक्स बनाए हैं:

ग्राफक्यूएल रिस्पांस टाइम (जीआरटी): के लिए राउंड ट्रिप समय अनुरोध को पूरा करने के लिए aphQL सेवा।

अपस्ट्रीम रिस्पांस टाइम (यूआरटी): के लिए राउंड ट्रिप का समय

एपीआई गेटवे एक बैकएंड की सेवा के लिए सर्विस। होते हैं

बैकएंड विलंबता का प्रतिनिधित्व करने के लिए एक अच्छा स्कोर निर्धारित करने के लिए, हमने कई बिंदुओं पर विचार किया: होते से उपयोगकर्ता का दृष्टिकोण, सिस्टम प्रतिक्रिया समय लगता है होते तत्काल जब यह 1s से कम हो

हमें यह भी ध्यान रखना होगा कि नेटवर्क लागत 50ms-500ms . के बीच भिन्न हो सकती है , इस पर निर्भर करता है कि उपयोगकर्ता किस क्षेत्र से हमारे उत्पाद तक पहुंच रहा है।

  • अंक 1 और 2 के आधार पर, ग्राफक्यूएल विलंबता 500ms से अधिक नहीं होनी चाहिए, जिसका अर्थ है कि अपस्ट्रीम सेवाओं को 300ms से कम में जवाब देना चाहिए क्योंकि GraphQL प्रश्नों को सबसे धीमे समापन बिंदु का इंतजार करना पड़ता है। इसलिए, हमने निष्कर्ष निकाला कि जीआरटी अच्छे स्कोर के लिए सीमा 500ms है, और URT अच्छा स्कोर 300ms है। हों बैकएंड विटल्स के लिए हमारा लक्ष्य कम से कम है 99 प्रतिशत माप
    प्रत्येक लॉग किए गए अनुरोध को पूरा करने के लिए “अच्छा” सीमा।

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

    बैकएंड विटल्स

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

    प्रदर्शन महत्वपूर्ण खोज योग्यता और प्राथमिकता

    उसी

    मीट्रिक स्कोरिंग का उपयोग करना और

    एट्रिब्यूशन

    व्यवस्था कॉइनबेस पर विभिन्न विशिष्टताओं में अवसर के क्षेत्रों की पहचान करना आसान बनाता है और प्रदर्शन प्रयासों में फ्रंटएंड और बैकएंड इंजीनियरों दोनों को संरेखित करता है।

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

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

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

  • प्रदर्शन महत्वपूर्ण के रूप में केआर योजना के लिए एकदम सही हैं 0 से 100 तक के स्कोर को मापते हैं और उन्हें आसानी से एक वर्ष से अधिक समय तक संग्रहीत किया जा सकता है। सभी प्रदर्शन KRs के लिए सामान्य भाषा भी संगठन में टीमों के लिए साझा लक्ष्य बनाना आसान बनाती है। हुए हो रहे अपने केआर को फ्रेम करने के कुछ उदाहरण:
  • [वर्ष केआर] कॉइनबेस मोबाइल ऐप में 70% से ऊपर एनटीबीटी के अच्छे स्कोर 90% तक पहुंचें .

      होते [तिमाही केआर] Coinbase वेब में LCP अच्छे स्कोर को 70% से 85% तक सुधारें।

      अगला

    खा एपीआई रिग्रेशन पर काम करने वाली एक छोटी टीम से लेकर कई संगठनों के नेतृत्व में बड़ी पहल तक, एक ही भाषा बोलने से सभी प्रकार के उत्पाद प्राथमिकता में मदद मिलती है।

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

    हों

    Share this:

    Like this:

    Like Loading...
    Check Also
    Close
    Back to top button
    %d bloggers like this: