PRFRL - एनालिटिक्स इंटरफ़ेस कैसे काम करता है

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

PRFLR अनुप्रयोगों में प्रदर्शन समस्याओं का जल्द से जल्द पता लगाने के उद्देश्य से एक विश्लेषिकी प्रणाली है। रीयलटाइम और सीधे उत्पादन सर्वर पर।

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

संकल्पना

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

कोड के एक टुकड़े के निष्पादन के समय को समझने के लिए, हम टाइमर का उपयोग करते हैं - यह एक इकाई है जो जानता है कि कोड को क्या कहा जाता है, यह जानता है कि इसे किस वातावरण में निष्पादित किया गया है, और इसे कितना समय लगा। उदाहरण के लिए: [mysite.ru, dellete_user_from_db, 0,03s] पर्याप्त समय के लिए ऐसी टाइमर संचित करने के बाद, हम इस डेटा का विश्लेषण करना शुरू कर सकते हैं।

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

रॉ टाइमर

पहली स्क्रीन सिर्फ टाइमर की एक कच्ची धारा है, जहां आप देख सकते हैं कि क्या कोड बिल्कुल काम करता है :) स्क्रीन पर आप 5 मिलियन पैरामीटर देख सकते हैं

• स्रोत - टाइमर का स्रोत। साइट, आईपी, आवेदन नाम हो सकता है
• टाइमर टाइमर का नाम है। जो नाम आप समझते हैं वह कोड का एक टुकड़ा है। आमतौर पर फ़ंक्शन / वर्ग से मेल खाने के लिए निर्धारित किया जाता है
• जानकारी - टाइमर के बारे में अतिरिक्त जानकारी, उदाहरण के लिए, एक फ़ंक्शन का परिणाम, एपीआई का संस्करण, अंतिम प्रतिबद्ध का लेखक :)
• थ्रेड - जिस थ्रेड में टाइमर निष्पादित किया गया था वह कोड में एकल डलनेस के विश्लेषण में मदद करता है।
• समय एक एकल टाइमर निष्पादन दिखाते हुए मिलीसेकंड है।

इस स्क्रीन को देखते हुए, यह स्पष्ट है कि MongoDB में पिछले 4 अनुरोधों को सिस्टम में निष्पादित किया गया था। 3 - 0.04ms के लिए और 0.05ms के लिए एक

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

सांख्यिकीय

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

निम्नलिखित मान उपलब्ध हैं:

• न्यूनतम, औसत, अधिकतम - क्रमशः, न्यूनतम और अधिकतम टाइमर रनटाइम
• गिनती - टाइमर की कुल संख्या
• कुल - इस प्रकार के सभी टाइमर का कुल निष्पादन समय

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

और इसका उपयोग कैसे करें?

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

उदाहरण के लिए, खोज बार में "* / mongo / * / *" मान दर्ज करते हुए, हमें mongoDB के साथ काम करने से संबंधित सभी टाइमर मिलते हैं। समूहीकरण चयनकर्ता स्विच करके हम तुरंत 3 प्रश्नों का उत्तर दे सकते हैं:

1. source - किस सर्वर पर mongoDB सबसे धीरे काम कर रहा है
2. टाइमर - जो अनुरोध एक पूरे के रूप में सिस्टम में सबसे अधिक समस्याग्रस्त है
3. source + टाइमर - किस विशिष्ट सर्वर पर अनुरोध करें जो खराब काम कर रहा है

अंतिम समूह विकल्प कभी-कभी बहुत अधिक डेटा देता है, इसलिए खोज बार में सर्वर नाम निर्दिष्ट करके किसी विशिष्ट सर्वर द्वारा डेटा को फ़िल्टर करना अधिक सुविधाजनक होता है।

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

आप स्वयं इसका उपयोग कैसे करते हैं?

PRFLR बहुत समय पहले किया जाना शुरू हुआ था, लेकिन सबसे अधिक गंभीरता से इसका उपयोग एक मोबाइल एप्लिकेशन के वितरित सर्वर बैकएंड के जियो-चेक का विश्लेषण करने के लिए किया गया था। सर्वर 3 महाद्वीपों पर 5 अलग-अलग डेटा केंद्रों में स्थित थे। और प्रत्येक सर्वर हार्डवेयर में अद्वितीय था। 32 जीबी रैम के साथ 8 न्यूक्लियर क्सीनन से, 500MB मेमोरी वाली वर्चुअल मशीन तक। कुछ ही दिनों में, हमने प्रदर्शन में लगभग सभी जामों को ढूंढ लिया और उन्हें ठीक कर दिया। प्रत्येक रिलीज के बाद काम का एक नियमित विश्लेषण नई समस्याओं को प्रकट करने की अनुमति नहीं देता है।

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

रिलीज़ फ़ील्ड का बार-बार विश्लेषण करने में लगभग 5 मिनट का समय लगेगा। लेकिन यह वही है जो आपको आवश्यक है - आवश्यक विश्लेषण देने के लिए और कम से कम संभव अवधि के लिए।