अपने WebRTC एप्लिकेशन के प्रदर्शन की निगरानी करना आपके उपयोगकर्ता अनुभव में जबरदस्त सुधार कर सकता है

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

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

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

नियमित अनुप्रयोग निगरानी से लाभ:

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

WebRTC ऐप मॉनिटरिंग लोडेरो के साथ कैसे काम करता है

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

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

Loadero के साथ अपने WebRTC समाधान की निगरानी शुरू करने के लिए 3 भागों वाला एक सेटअप आवश्यक है:

1. एक लोडेरो परीक्षण जो आपके वेबआरटीसी ऐप के प्रदर्शन का आकलन करेगा। आप एक उदाहरण यहां ढूंढ सकते हैं।
2. एक स्क्रिप्ट जो परीक्षण शुरू करने, परिणाम प्राप्त करने और विफलता के बारे में सूचित करने के लिए Loadero API का उपयोग करती है।
3. स्क्रिप्ट को स्वचालित रूप से चलाने के लिए एक CI/CD पाइपलाइन।

निगरानी सेटअप के लिए एक परीक्षण की स्थापना

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

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

प्रतिभागी यूएस ओरेगन से जुड़ेंगे, नवीनतम Google क्रोम संस्करण (इस ब्लॉग को लिखने के समय 109v) का उपयोग करेंगे, और आउटपुट सिग्नल को अनुकरण करने के लिए डिफ़ॉल्ट वीडियो + ऑडियो का उपयोग करेंगे।

हम लोडेरो के पोस्ट-रन अभिकथन का भी उपयोग करेंगे। वे आपको अपने परीक्षण में WebRTC और/या मशीन मेट्रिक्स के लिए "पास" मानदंड निर्दिष्ट करने की अनुमति देते हैं, जैसे "यदि औसत FPS ≥ 10 है, तो पास करें"। रन पूरा होने के बाद, दिए गए मान पास मानदंडों को पूरा करते हैं या नहीं, यह जांचने के लिए प्रत्येक प्रतिभागी के लिए स्वचालित रूप से परिणामों की गणना की जाती है। यदि किसी प्रतिभागी के लिए अभिकथन विफल हो जाता है, तो परिणाम रिपोर्ट में इस प्रतिभागी की स्थिति भी "विफल" होगी।

अभिकथनों के साथ, हम ऑडियो और वीडियो दोनों के साथ-साथ FPS के लिए इनकमिंग और आउटकमिंग बिटरेट और पैकेट का आकलन करेंगे।

हमारे परीक्षण का विन्यास कुछ इस प्रकार होगा:

• टेस्ट मोड: 'प्रदर्शन परीक्षण'
• वृद्धि की रणनीति: 'रैखिक भागीदार'
• प्रारंभ अंतराल: 1s
• प्रतिभागी टाइमआउट: 5 मिनट

इस उदाहरण में हमारे पास जावास्क्रिप्ट + नाइटवॉच में लोडरो टेस्ट स्क्रिप्ट लिखी गई है, लेकिन जावा + टेस्टयूआई या पायथन + पाय-टेस्टयूआई के साथ भी ऐसा ही किया जा सकता है।

 client => { client // Open the page .url(`https://meet.jit.si/LoaderoTests`) // Wait until the username field is visible // And enter the username .waitForElementVisible('[placeholder]', 30 * 1000) .sendKeys('[placeholder]', 'User') // Wait until the "Join" button is visible // And join the call by pressing the button .waitForElementVisible('[aria-label="Join meeting"]', 10 * 1000) .click('[aria-label="Join meeting"]') // Another thing you can do is to take screenshots during the test // Which could help you to identify the cause of a failure // And give visual feeback about the test run .takeScreenshot('pre_call_screenshot.png') // Stay in the call for half a minute .pause(30 * 1000) // Take a mid-call screenshot .takeScreenshot('mid_call_screenshot.png') // Stay in the call for another half a minute .pause(30 * 1000) // Take a post-call screenshot .takeScreenshot('post_call_screenshot.png'); }

WebRTC प्रदर्शन अपेक्षाओं को सेट करना

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

यहां अभिकथनों और उनके मूल्यों की सूची दी गई है जो हमने इस उदाहरण परीक्षण के लिए निर्धारित किए हैं:

• दावा करें कि इनकमिंग और आउटगोइंग दोनों वीडियो स्ट्रीम में 75% से अधिक कॉल अवधि के लिए वीडियो में प्रति सेकंड कम से कम 10 फ्रेम हैं। इसके अतिरिक्त, मानक विचलन पर अभिकथन सेट करके जांचें कि फ्रैमरेट में उतार-चढ़ाव छोटे हैं, प्रति सेकंड 2 फ्रेम से अधिक नहीं:

  • webrtc/video/fps/out/25th >= 10

  • webrtc/video/fps/in/25th >= 10

  • webrtc/video/fps/out/stddev < 2

  • webrtc/video/fps/in/stddev < 2

    
    

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

  • webrtc/audio/packets/out/avg > 40/sec

  • webrtc/video/packets/out/avg > 100/sec

  • webrtc/audio/packets/in/avg > 40/sec

  • webrtc/video/packets/in/avg > 100/sec

    
    

• बिटरेट प्रति सेकंड भेजे गए डेटा की मात्रा को इंगित करता है। आम तौर पर उच्च गुणवत्ता वाला मीडिया भेजा जाता है, बिटरेट जितना अधिक होता है। हालांकि कुछ एप्लिकेशन खराब नेटवर्क पर बेहतर काम करने और कम डेटा की खपत करने के लिए बिटरेट को कम करने का प्रयास करेंगे। इन दावों के साथ हम जाँचते हैं कि डेटा खपत इनकमिंग और आउटगोइंग ऑडियो के लिए 25 kbit/sec और इनकमिंग और आउटगोइंग वीडियो के लिए 1000 kbit/sec के निर्धारित मान से 95% परीक्षण अवधि से अधिक नहीं है:
  • webrtc/audio/bitrate/out/95th <= 25 kbit/sec
  • webrtc/video/bitrate/out/95th <= 1000 kbit/sec
  • webrtc/audio/bitrate/in/95th <= 25 kbit/sec
  • webrtc/video/bitrate/in/95th <= 1000 kbit/sec

परीक्षण प्रतिभागियों को कॉन्फ़िगर करना और परीक्षण चलाना

अंत में, हमें परीक्षण प्रतिभागियों को कॉन्फ़िगर करना होगा। हमारे पास प्रतिभागियों का 1 समूह होने जा रहा है जिसमें समान कॉन्फ़िगरेशन वाले 2 प्रतिभागी होंगे जो कॉल में शामिल होंगे। प्रतिभागियों का सेटअप निम्न है:

• शीर्षक - 'प्रतिभागी'
• गणना – 2
• गणना इकाइयां: G2
• ब्राउज़र - 'नवीनतम Google Chrome'
• स्थान - 'यूएस वेस्ट - ओरेगन'
• नेटवर्क - 'डिफ़ॉल्ट नेटवर्क सेटिंग्स'
• ऑडियो फ़ीड - 'डिफ़ॉल्ट ऑडियो फ़ीड'
• वीडियो फ़ीड - 'डिफ़ॉल्ट वीडियो फ़ीड'

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

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

जैसा कि पहले उल्लेख किया गया है, यदि WebRTC मीट्रिक अभिकथन विफल हो जाते हैं और सफलता दर 100% नहीं हो सकती है, तो प्रतिभागी अभी भी विफल हो सकते हैं। यह हमारे परीक्षण के लिए भी हुआ।

इसका अनिवार्य रूप से यह अर्थ नहीं है कि परीक्षण दोषपूर्ण है, केवल यह कि ऐप आपके द्वारा निर्धारित अभिकथन मानदंडों को पूरा नहीं करता है। लेकिन अगर आपका परीक्षण किसी अन्य कारण से विफल हुआ, न कि अभिकथन सेट से, यह ब्लॉग पोस्ट आपके परीक्षण को डीबग करने के कुछ तरीके बताता है।

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

युक्ति: अपने स्वयं के दावे सेट करने का एक अच्छा तरीका 5 टेस्ट रन करना होगा, प्रतिभागी मेट्रिक्स को देखें और उचित लक्ष्यों का मूल्यांकन करें।

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

पाइपलाइन से नियमित रूप से परीक्षण शुरू करना

हमारी टीम ने आपके विकास पाइपलाइन में परीक्षणों को एकीकृत करने के तरीके पर कुछ ब्लॉग पोस्ट पहले ही तैयार कर लिए हैं: JS और Loadero के Python क्लाइंट का उपयोग करना। इसलिए यहां हम उन पर भरोसा करने जा रहे हैं। हमारे सेटअप के लिए हम उस ब्लॉग पोस्ट का उपयोग करेंगे जो पायथन, गिटहब और इसके सीआई/सीडी कार्यान्वयन का उपयोग करता है - लोडरो पायथन क्लाइंट के साथ वर्कफ़्लोज़।

नोट: कुछ जानकारी छोड़ी जा सकती है। गहन निर्देशों के लिए मूल Loadero Python ब्लॉग पोस्ट देखें।

हमारे वर्कफ़्लो के लिए हमें आवश्यकता होगी:

• एक गिटहब भंडार
• एक YAML फ़ाइल जो वर्कफ़्लो को परिभाषित करती है
• लोडेरो परीक्षण चलाने और परिणामों की रिपोर्ट करने के लिए एक पायथन स्क्रिप्ट

GitHub पर एक नया रिपॉजिटरी बनाएं या मौजूदा रिपॉजिटरी का उपयोग करें।

.github/workflows निर्देशिका में आपके रिपॉजिटरी में एक notify-on-fail.yml फ़ाइल बनाएँ। यह वह फाइल है जिसमें पर्यावरण को कैसे स्थापित किया जाए और लोडेरो परीक्षण कैसे शुरू किया जाए, इस पर निर्देश शामिल होने जा रहे हैं।

चलिए notify-on-fail.yml में ट्रिगर निर्दिष्ट करके कार्यप्रवाह को परिभाषित करना शुरू करते हैं।

 on: schedule: - cron: '0 9-18 * * *' workflow_dispatch:

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

युक्ति : परीक्षणों की आवृत्ति निर्धारित करते समय, विचार करें कि परीक्षण चलाने के बीच की अवधि परीक्षण की अवधि से अधिक होनी चाहिए, क्योंकि आपके परीक्षण एक दूसरे के साथ हस्तक्षेप कर सकते हैं।

दूसरा ट्रिगर - workflow_dispatch - यदि आवश्यक हो तो गिटहब वेब एप्लिकेशन के माध्यम से पाइपलाइन को मैन्युअल रूप से ट्रिगर करने की अनुमति देता है।

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

 jobs: notify-on-fail: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 with: python-version: "3.10" - run: pip install loadero-python - run: python run.py env: LOADERO_ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }} LOADERO_PROJECT_ID: ${{ secrets.PROJECT_ID }} LOADERO_TEST_ID: ${{ secrets.TEST_ID }}

महत्वपूर्ण: ध्यान दें, कि लाइन - run: python run.py में, अजगर के बाद हमारे पास रिपॉजिटरी के रूट के सापेक्ष आपकी run.py फ़ाइल का पथ है। मेरे मामले में फ़ाइल संरचना इस तरह दिखेगी:

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

रहस्यों के बारे में विस्तृत चरण-दर-चरण निर्देशों के लिए पहले उल्लिखित ब्लॉग पोस्ट देखें।

तो अब के लिए कार्यप्रवाह विन्यास कुछ इस तरह दिखना चाहिए:

 name: Notify about failing tests in Loadero on: schedule: - cron: '0 9-18 * * *' workflow_dispatch: jobs: notify-on-fail: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 with: python-version: "3.10" - run: pip install loadero-python - run: python run.py env: LOADERO_ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }} LOADERO_PROJECT_ID: ${{ secrets.PROJECT_ID }} LOADERO_TEST_ID: ${{ secrets.TEST_ID }}

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

 import os from loadero_python.api_client import APIClient from loadero_python.resources.test import Test project_id = os.environ.get("LOADERO_PROJECT_ID", None) access_token = os.environ.get("LOADERO_ACCESS_TOKEN", None) test_id = os.environ.get("LOADERO_TEST_ID", None) if project_id is None or access_token is None or test_id is None: raise Exception( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) APIClient( project_id=project_id, access_token=access_token, ) run = Test(test_id=test_id).launch().poll() print(run) for result in run.results()[0]: print(result) if run.params.success_rate != 1: raise Exception("Test failed")

विफल परीक्षणों के बारे में सूचनाएं भेजना

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

आइए रिक्वेस्ट लाइब्रेरी, ResultStatus और AssertStatus क्लासेस को इम्पोर्ट करके अपनी पायथन फाइल को अपडेट करें।

 import requests import os from loadero_python.api_client import APIClient from loadero_python.resources.test import Test from loadero_python.resources.classificator import ResultStatus, AssertStatus

साथ ही अनुरोध पुस्तकालय स्थापित करने के लिए हमारी वाईएएमएल फ़ाइल को अपडेट कर रहा है।

 - run: pip install loadero-python - run: pip install requests - run: python run.py

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

 missing_credentials_message = ( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) def send_notification(message): requests.post( "https://discordapp.com/api/webhooks/{id}", data={"content": message}, ) if project_id is None or access_token is None or test_id is None: send_notification(missing_credentials_message) raise Exception(missing_credentials_message)

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

• प्रतिभागियों का नाम
• सेलेनियम परिणाम
• दर्जा
• जोर देने का मार्ग विफल हो रहा है
• चलने की स्थिति

इसके अतिरिक्त हमें प्रारंभिक लिपि के अपवाद से छुटकारा पाना चाहिए, क्योंकि यह यहाँ अत्यधिक है

 run_failure_message = "" for result in run.results()[0]: result.params.run_id = run.params.run_id result.read() if ( result.params.selenium_result.value != ResultStatus.RS_PASS or result.params.status.value != ResultStatus.RS_PASS ): run_failure_message += ( f"{result.params.participant_details.participant_name}:\n" f"-Selenium result: {result.params.selenium_result.value}\n" f"-Participant status: {result.params.status.value}\n" ) if result.params.asserts: run_failure_message += "-Failing asserts:\n" for assertion in result.params.asserts: if assertion.status != AssertStatus.AS_PASS: run_failure_message += f"--{assertion.path.value}\n" run_failure_message += "\n" run_failure_message += f"Run status: {run.params.status.value}" if run.params.success_rate != 1: send_notification(run_failure_message)

और आइए सफल परीक्षण के लिए एक संदेश भी भेजें:

 if run.params.success_rate != 1: send_notification(run_failure_message) else: send_notification(f"The {run.params.test_name} test has been finished successfully")

अंतिम सत्यापन के रूप में हमें संपूर्ण एपीआई कॉल को try-except । अंतिम अजगर स्क्रिप्ट पूरी तरह से इस तरह दिखती है:

 import os import requests from loadero_python.api_client import APIClient from loadero_python.resources.test import Test from loadero_python.resources.classificator import ResultStatus, AssertStatus project_id = os.environ.get("LOADERO_PROJECT_ID", None) access_token = os.environ.get("LOADERO_ACCESS_TOKEN", None) test_id = os.environ.get("LOADERO_TEST_ID", None) missing_credentials_message = ( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) def send_notification(message): requests.post( "https://discordapp.com/api/webhooks/{id}", data={"content": message}, ) if project_id is None or access_token is None or test_id is None: send_notification(missing_credentials_message) raise Exception(missing_credentials_message) try: APIClient( project_id=project_id, access_token=access_token, ) run = Test(test_id=test_id).launch().poll() print(run) run_failure_message = "" for result in run.results()[0]: result.params.run_id = run.params.run_id result.read() if ( result.params.selenium_result.value != ResultStatus.RS_PASS or result.params.status.value != ResultStatus.RS_PASS ): run_failure_message += ( f"{result.params.participant_details.participant_name}:\n" f"-Selenium result: {result.params.selenium_result.value}\n" f"-Participant status: {result.params.status.value}\n" ) if result.params.asserts: run_failure_message += "-Failing asserts:\n" for assertion in result.params.asserts: if assertion.status != AssertStatus.AS_PASS: run_failure_message += f"--{assertion.path.value}\n" run_failure_message += "\n" run_failure_message += f"Run status: {run.params.status.value}" if run.params.success_rate != 1: send_notification(run_failure_message) else: send_notification( f"The {run.params.test_name} test has been finished successfully" ) except Exception as err: send_notification(f"Error while running Loadero test: {err}")

WebRTC निगरानी परिणामों का निरीक्षण

अब हमारा परीक्षण स्वचालित रूप से हर घंटे सुबह 9 बजे से शाम 6 बजे तक चलता है और यह आकलन करता है कि ऐप अपेक्षा के अनुरूप प्रदर्शन करता है या नहीं।

परीक्षण निष्पादन समाप्त होने के बाद, परीक्षण में विफल होने की स्थिति में आपको विफलता के बारे में सूचित किया जाता है।

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

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

ध्यान दें: केवल अपने परीक्षण के अभिकथनों को देखकर हम यह नोट कर सकते हैं कि ऐसे संपूर्ण खंड हैं जो पूरे परीक्षण के दौरान शून्य का उत्पादन करते हैं, जो अंततः परीक्षण के परिणामों को प्रभावित करता है।

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

इस ब्लॉग पोस्ट में, हमने एक उदाहरण प्रदान किया है कि कैसे आप Loadero और GitHub वर्कफ़्लोज़ की सहायता से अपने WebRTC एप्लिकेशन की निगरानी कर सकते हैं। मॉनिटरिंग के उपयोग से आप अपने आवेदन में उत्पन्न होने वाली किसी भी समस्या से निपटने के लिए बेहतर ढंग से सुसज्जित हैं। एप्लिकेशन के प्रदर्शन पर अधिक समग्र दृष्टिकोण के लिए विभिन्न स्थितियों के साथ अन्य परिदृश्य बनाना भी बुद्धिमानी हो सकती है। इस तरह की मॉनिटरिंग सेट करना काफी जटिल काम हो सकता है। क्या आप लोडेरो टीम को आपके लिए एक समान निगरानी सेटअप बनाना चाहेंगे? बेझिझक हमसे [email protected] पर संपर्क करें और आइए इस पर चर्चा करें कि हम आपके WebRTC समाधान की नियमित और स्वचालित रूप से निगरानी करने में आपकी सहायता कैसे कर सकते हैं।