परफ़ॉर्मेंस मॉनिटर करने से जुड़ी समस्या हल करना और अक्सर पूछे जाने वाले सवाल
संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
इस पेज पर, Performance Monitoring का इस्तेमाल शुरू करने या Performance Monitoring की सुविधाओं और टूल का इस्तेमाल करने से जुड़ी समस्याओं को हल करने के बारे में सलाह दी गई है.
समस्या हल करने के लिए सबसे पहले ये काम करें
यहां दो सामान्य जांचों के बारे में बताया गया है. इन्हें गड़बड़ी ठीक करने के लिए आगे की कार्रवाई करने से पहले, हर व्यक्ति को आज़माना चाहिए.
1. परफ़ॉर्मेंस इवेंट के लिए लॉग मैसेज देखना
अपने लॉग मैसेज देखें. इससे यह पक्का किया जा सकेगा कि Performance Monitoring SDK, परफ़ॉर्मेंस इवेंट कैप्चर कर रहा है.
कुछ सेकंड बाद, अपने ब्राउज़र के डेवलपर टूल में firebaselogging.googleapis.com पर नेटवर्क कॉल देखें. इस नेटवर्क कॉल से पता चलता है कि ब्राउज़र, परफ़ॉर्मेंस डेटा को Firebase पर भेज रहा है.
अगर Firebase या Performance Monitoring में कोई ऐसी समस्या है जिसके बारे में पहले से जानकारी है, तो Firebase का स्टेटस डैशबोर्ड देखें.
Performance Monitoring का इस्तेमाल शुरू करना
अगर आपको Performance Monitoring
(iOS+ |
Android |
Web) का इस्तेमाल शुरू करना है, तो समस्या हल करने से जुड़ी ये सलाह आपके काम आ सकती हैं. इनसे उन समस्याओं को हल करने में मदद मिल सकती है जिनमें Firebase को SDK टूल का पता लगाने या Firebase कंसोल में परफ़ॉर्मेंस का पहला डेटा दिखाने में समस्या आ रही है.
ऐप्लिकेशन में एसडीके टूल जोड़ा गया है, लेकिन कंसोल में अब भी एसडीके टूल जोड़ने का मैसेज दिख रहा है
जब Firebase को आपके ऐप्लिकेशन से इवेंट की जानकारी (जैसे, ऐप्लिकेशन के साथ इंटरैक्शन) मिलती है, तब वह यह पता लगा सकता है कि आपने अपने ऐप्लिकेशन में Performance Monitoring SDK टूल को सही तरीके से जोड़ा है या नहीं.
आम तौर पर, ऐप्लिकेशन शुरू करने के 10 मिनट के अंदर, Firebase कंसोल के परफ़ॉर्मेंस डैशबोर्ड पर "एसडीके टूल का पता चला" मैसेज दिखता है. फिर, 30 मिनट के भीतर, डैशबोर्ड प्रारंभिक संसाधित डेटा प्रदर्शित करता है.
अगर आपने अपने ऐप्लिकेशन में एसडीके का नया वर्शन जोड़े हुए 10 मिनट से ज़्यादा हो गए हैं और आपको अब भी कोई बदलाव नहीं दिख रहा है, तो अपने लॉग मैसेज देखें. इससे यह पक्का किया जा सकेगा कि Performance Monitoring इवेंट लॉग कर रहा है. एसडीके का पता लगाने में देरी होने से जुड़ा मैसेज मिलने की समस्या हल करने के लिए, यहां दिया गया तरीका आज़माएं.
ऐप्लिकेशन इवेंट लॉग कर रहा है: समस्या हल करने का तरीका
अगर अब भी स्थानीय तौर पर डेवलपमेंट किया जा रहा है, तो डेटा इकट्ठा करने के लिए ज़्यादा इवेंट जनरेट करें:
अपने वेब ऐप्लिकेशन को लोकल एनवायरमेंट में चलाएं और देखें.
अपनी साइट के सबपेज लोड करके, अपने ऐप्लिकेशन से इंटरैक्ट करके, और/या नेटवर्क अनुरोध ट्रिगर करके इवेंट जनरेट करें. पेज लोड होने के बाद, ब्राउज़र टैब को कम से कम 10 सेकंड तक खुला रखें.
पक्का करें कि आपके ऐप्लिकेशन में Firebase कॉन्फ़िगरेशन ऑब्जेक्ट सही तरीके से जोड़ा गया हो और आपने ऑब्जेक्ट में कोई बदलाव न किया हो. खास तौर पर, इनकी जांच करें:
कॉन्फ़िगरेशन ऑब्जेक्ट में मौजूद Firebase वेब ऐप्लिकेशन आईडी (appId) आपके ऐप्लिकेशन के लिए सही है. settingsप्रोजेक्ट की सेटिंग में मौजूद आपके ऐप्लिकेशन कार्ड में जाकर, अपना Firebase ऐप्लिकेशन आईडी ढूंढें.
अगर आपको अपने ऐप्लिकेशन में कॉन्फ़िगरेशन ऑब्जेक्ट में कोई गड़बड़ी दिखती है, तो यह तरीका आज़माएं:
अपने ऐप्लिकेशन में मौजूद कॉन्फ़िग ऑब्जेक्ट को मिटाएं.
नया कॉन्फ़िगरेशन ऑब्जेक्ट पाने और उसे अपने वेब ऐप्लिकेशन में जोड़ने के लिए, इन निर्देशों का पालन करें.
अगर एसडीके इवेंट लॉग कर रहा है और सब कुछ सही तरीके से सेट अप किया गया है, लेकिन आपको अब भी एसडीके का पता चलने से जुड़ा मैसेज या प्रोसेस किया गया डेटा नहीं दिख रहा है (दो घंटे बाद भी), तो Firebase की सहायता टीम से संपर्क करें.
ऐप्लिकेशन में इवेंट लॉग नहीं हो रहे हैं:
समस्या हल करने का तरीका
पक्का करें कि आपके ऐप्लिकेशन में Performance Monitoring SDK टूल को सही तरीके से शुरू किया गया हो.
पक्का करें कि Performance Monitoring SDK टूल को इस फ़्लैग के ज़रिए बंद न किया गया हो:
performance.instrumentationEnabled
पक्का करें कि आपके ब्राउज़र में कैश मेमोरी सेव करने की सुविधा बंद हो. ऐसा न होने पर, ब्राउज़र नई इंस्ट्रुमेंटेशन सेटिंग को पिक अप नहीं कर पाएगा.
वेबपेज टैब को बंद करें और फिर से खोलें. फिर से लॉग इन करके देखें.
अगर आपने अभी-अभी अपने ऐप्लिकेशन में Performance Monitoring SDK टूल जोड़ा है, तो हो सकता है कि आपको अपने ऐप्लिकेशन को पूरी तरह से रीस्टार्ट करना पड़े, ताकि SDK टूल काम करना शुरू कर दे.
अगर आपने SDK टूल को जोड़ लिया है और अपने ऐप्लिकेशन में Performance Monitoring का इस्तेमाल किया जा रहा है, तो समस्या हल करने से जुड़ी यहां दी गई सलाह से, Performance Monitoring की सुविधाओं और टूलिंग से जुड़ी सामान्य समस्याओं को हल करने में मदद मिल सकती है.
पक्का करें कि आपके ऐप्लिकेशन में Performance Monitoring SDK टूल को सही तरीके से शुरू किया गया हो.
पक्का करें कि Performance Monitoring SDK टूल को इस फ़्लैग के ज़रिए बंद न किया गया हो:
performance.instrumentationEnabled
पक्का करें कि आपके ब्राउज़र में कैश मेमोरी सेव करने की सुविधा बंद हो. ऐसा न होने पर, ब्राउज़र नई इंस्ट्रुमेंटेशन सेटिंग को पिक अप नहीं कर पाएगा.
वेबपेज टैब को बंद करें और फिर से खोलें. फिर से लॉग इन करके देखें.
अगर आपने अभी-अभी अपने ऐप्लिकेशन में Performance Monitoring SDK टूल जोड़ा है, तो हो सकता है कि आपको अपने ऐप्लिकेशन को पूरी तरह से रीस्टार्ट करना पड़े, ताकि SDK टूल काम करना शुरू कर दे.
ध्यान दें कि Performance Monitoring, पहले इनपुट में लगने वाले समय की मेट्रिक को सिर्फ़ तब रिकॉर्ड करता है, जब कोई उपयोगकर्ता पेज लोड होने के पांच सेकंड के अंदर वेब पेज पर क्लिक करता है.
पक्का करें कि आपने इस मेट्रिक को मेज़र करने के लिए, अपने ऐप्लिकेशन को सेट अप किया हो. फ़र्स्ट इनपुट डिले मेट्रिक के लिए, मैन्युअल सेटअप की ज़रूरत होती है.
खास तौर पर, आपको इस मेट्रिक के लिए पॉलीफ़िल लाइब्रेरी जोड़नी होगी. इंस्टॉल करने के निर्देशों के लिए, लाइब्रेरी का दस्तावेज़ देखें.
ध्यान दें कि Performance Monitoring को अन्य वेब ऐप्लिकेशन मेट्रिक रिपोर्ट करने के लिए, इस पॉलीफ़िल लाइब्रेरी को जोड़ने की ज़रूरत नहीं है.
परफ़ॉर्मेंस डैशबोर्ड में, कस्टम ट्रेस का डेटा मौजूद नहीं है
क्या आपको अपने-आप इकट्ठा किए गए ट्रेस के लिए परफ़ॉर्मेंस डेटा दिख रहा है, लेकिन कस्टम कोड ट्रेस के लिए नहीं? समस्या हल करने के लिए, यह तरीका आज़माएं:
ट्रेस API के ज़रिए इंस्ट्रूमेंट किए गए कस्टम कोड ट्रेस के सेटअप की जाँच करें, खास तौर पर निम्नलिखित:
कस्टम कोड ट्रेस और कस्टम मेट्रिक के नाम इन ज़रूरी शर्तों को पूरा करते हों: नाम की शुरुआत या आखिर में कोई खाली जगह न हो, नाम की शुरुआत में अंडरस्कोर
(_) वर्ण न हो, और नाम की ज़्यादा से ज़्यादा लंबाई 32 वर्ण हो.
सभी ट्रेसों को शुरू और बंद किया जाना चाहिए. कोई भी ट्रेस जो शुरू नहीं किया गया है, बंद नहीं किया गया है, या शुरू होने से पहले बंद कर दिया गया है, उसे लॉग नहीं किया जाएगा.
ध्यान दें कि अगर record() तरीके का इस्तेमाल किया जा रहा है, तो आपको ट्रेस को साफ़ तौर पर शुरू या बंद करने की ज़रूरत नहीं है.
परफ़ॉर्मेंस डैशबोर्ड में नेटवर्क अनुरोध का डेटा मौजूद नहीं है
अगर आपको नेटवर्क अनुरोध का डेटा नहीं दिख रहा है, तो इन बातों का ध्यान रखें:
Performance Monitoring, ब्राउज़र एपीआई से रिपोर्ट किए गए नेटवर्क अनुरोधों के लिए मेट्रिक अपने-आप इकट्ठा करता है. इन रिपोर्ट में, नेटवर्क के ऐसे अनुरोध शामिल नहीं होते हैं जो पूरे नहीं हो सके.
आपके कोड के व्यवहार और आपके कोड में इस्तेमाल की गई नेटवर्किंग लाइब्रेरी के आधार पर, Performance Monitoring सिर्फ़ उन नेटवर्क अनुरोधों की रिपोर्ट कर सकता है जो पूरे हो चुके हैं.
इसका मतलब है कि खुले हुए एचटीटीपी/एस कनेक्शन की जानकारी नहीं दी जा सकती.
नेटवर्क अनुरोध का डेटा, उम्मीद के मुताबिक एग्रीगेट नहीं हो रहा है
Project home पर मौजूद परफ़ॉर्मेंस कार्ड में, सबसे ज़्यादा असर डालने वाली समस्याओं का क्या हुआ?
हमने सबसे ज़्यादा समस्याएं की जगह हाल के अलर्ट को शामिल किया है. ऐसा इसलिए किया गया है, क्योंकि हमने हाल ही में अलर्ट की सुविधा लॉन्च की है. इस सुविधा के तहत, तय की गई सीमाएं पार होने पर आपको अपने-आप सूचनाएं मिलती हैं. समस्याएं अब बंद कर दी गई हैं और उनकी जगह सूचनाओं को शामिल कर दिया गया है.
परफ़ॉर्मेंस कार्ड में सबसे ऊपर मौजूद ऐप्लिकेशन चुनने वाले टूल की मदद से, हाल ही की सूचनाएं में मौजूद सूचनाओं को फ़िल्टर किया जा सकता है. चुने गए ऐप्लिकेशन के लिए, सिर्फ़ तीन सबसे हाल की चेतावनियां दिखाई जाती हैं.
कंसोल में समस्याओं के लिए थ्रेशोल्ड सेट करने की सुविधा का क्या हुआ?
Performance Monitoring, तय की गई थ्रेशोल्ड से ज़्यादा होने वाली मेट्रिक के लिए सूचनाएं पाने की सुविधा देता है. परफ़ॉर्मेंस मेट्रिक के लिए कॉन्फ़िगर किए जा सकने वाले थ्रेशोल्ड की वजह से भ्रम की स्थिति पैदा हो सकती है. इसलिए, हमने समस्याओं के लिए थ्रेशोल्ड कॉन्फ़िगर करने की सुविधा हटा दी है.
Firebase कंसोल में, 'जानकारी और मेट्रिक' सेक्शन का क्या हुआ?
हमने समस्या हल करने के तरीके को बेहतर बनाने के लिए, 'जानकारी' और 'मेट्रिक' पेजों को नए सिरे से डिज़ाइन किए गए, एक ही जगह पर मौजूद यूज़र इंटरफ़ेस (यूआई) से बदल दिया है. समस्या हल करने वाले इस नए यूज़र इंटरफ़ेस (यूआई) में, वही मुख्य सुविधाएं मिलती हैं जो 'जानकारी' और 'मेट्रिक' में मिलती थीं. समस्या हल करने के बारे में ज़्यादा जानने के लिए, किसी खास ट्रेस के लिए ज़्यादा डेटा देखना लेख पढ़ें.
नमूनों की संख्या मेरी उम्मीद के मुताबिक क्यों नहीं है?
Performance Monitoring आपके ऐप्लिकेशन के उपयोगकर्ताओं के डिवाइसों से परफ़ॉर्मेंस का डेटा इकट्ठा करता है. अगर आपके ऐप्लिकेशन का इस्तेमाल कई लोग करते हैं या ऐप्लिकेशन से परफ़ॉर्मेंस से जुड़ी कई गतिविधियां जनरेट होती हैं, तो Performance Monitoring, डेटा कलेक्शन को डिवाइसों के सबसेट तक सीमित कर सकता है. ऐसा प्रोसेस किए गए इवेंट की संख्या को कम करने के लिए किया जाता है. ये सीमाएं इतनी ज़्यादा हैं कि कम इवेंट होने पर भी, मेट्रिक की वैल्यू से यह पता चलता है कि उपयोगकर्ता को ऐप्लिकेशन इस्तेमाल करने का कैसा अनुभव मिला.
हम जो डेटा इकट्ठा करते हैं उसकी मात्रा को मैनेज करने के लिए, Performance Monitoring इन सैंपलिंग विकल्पों का इस्तेमाल करता है:
डिवाइस पर रेट लिमिट तय करना: किसी डिवाइस से अचानक बहुत ज़्यादा ट्रेस न भेजे जाएं, इसके लिए हम किसी डिवाइस से भेजे जाने वाले कोड और नेटवर्क अनुरोध के ट्रेस की संख्या को सीमित करते हैं. यह सीमा, हर 10 मिनट में 300 इवेंट होती है. इस तरीके से, डिवाइस को लूप किए गए इंस्ट्रुमेंटेशन से बचाया जाता है. ये इंस्ट्रुमेंटेशन, परफ़ॉर्मेंस का ज़्यादा डेटा भेज सकते हैं. साथ ही, यह किसी एक डिवाइस को परफ़ॉर्मेंस मेज़रमेंट को गलत तरीके से दिखाने से रोकता है.
डाइनैमिक सैंपलिंग: Performance Monitoring हर दिन, ऐप्लिकेशन इस्तेमाल करने वाले सभी लोगों के लिए, ऐप्लिकेशन के हिसाब से कोड ट्रेस और नेटवर्क अनुरोध ट्रेस की सीमित संख्या इकट्ठा करता है. डाइनैमिक सैंपलिंग रेट को डिवाइसों पर फ़ेच किया जाता है. इसके लिए, Firebase Remote Config का इस्तेमाल किया जाता है. इससे यह तय किया जाता है कि किसी डिवाइस को ट्रेस कैप्चर करके भेजना चाहिए या नहीं. सैंपलिंग के लिए नहीं चुना गया डिवाइस, कोई भी इवेंट नहीं भेजता है. डाइनैमिक सैंपलिंग रेट, ऐप्लिकेशन के हिसाब से तय होता है. यह इस तरह से अडजस्ट होता है कि इकट्ठा किए गए डेटा का कुल वॉल्यूम, तय सीमा से कम रहे.
उपयोगकर्ता सेशन, उपयोगकर्ता के डिवाइस से ज़्यादा और ज़्यादा जानकारी वाला डेटा भेजते हैं. इसलिए, इस डेटा को कैप्चर और भेजने के लिए ज़्यादा संसाधनों की ज़रूरत होती है. उपयोगकर्ता सेशन के असर को कम करने के लिए, Performance Monitoring सेशन की संख्या को भी सीमित कर सकता है.
सर्वर-साइड पर दर सीमित करना: यह पक्का करने के लिए कि ऐप्लिकेशन, सैंपलिंग की सीमा से ज़्यादा डेटा न भेजें, Performance Monitoring सर्वर-साइड सैंपलिंग का इस्तेमाल कर सकता है. इससे डिवाइसों से मिले कुछ इवेंट को ड्रॉप किया जा सकता है. हालांकि, इस तरह की सीमा तय करने से हमारी मेट्रिक की परफ़ॉर्मेंस पर कोई असर नहीं पड़ता, लेकिन इससे पैटर्न में मामूली बदलाव हो सकते हैं. इनमें ये शामिल हैं:
ट्रेस की संख्या, कोड के किसी हिस्से को एक्ज़ीक्यूट किए जाने की संख्या से अलग हो सकती है.
कोड में एक-दूसरे से जुड़े हुए ट्रेस में, सैंपल की संख्या अलग-अलग हो सकती है.
कंसोल में समस्याएं टैब का क्या हुआ?
हमने 'समस्याएं' टैब की जगह चेतावनियों की सुविधा शुरू की है. यह सुविधा, आपके सेट किए गए थ्रेशोल्ड से ज़्यादा होने पर, आपको अपने-आप सूचना देती है. अब आपको थ्रेशोल्ड की स्थिति का पता लगाने के लिए, Firebase कंसोल को मैन्युअल तरीके से देखने की ज़रूरत नहीं है. चेतावनी की सुविधा के बारे में जानने के लिए, परफ़ॉर्मेंस से जुड़ी समस्याओं के लिए चेतावनियां सेट अप करना लेख पढ़ें.
कंसोल में मौजूद डिवाइस पर और नेटवर्क टैब का क्या हुआ?
मैं उन पृष्ठों पर मौजूद निशानों को कैसे देख सकता हूँ?
हमने Firebase कंसोल के Performance Monitoring सेक्शन को फिर से डिज़ाइन किया है ताकि डैशबोर्ड टैब आपके मुख्य मेट्रिक और आपके सभी ट्रेस को एक ही स्थान पर प्रदर्शित कर सके. पुनः डिज़ाइन के भाग के रूप में, हमने डिवाइस पर और नेटवर्क पृष्ठ हटा दिए हैं.
डैशबोर्ड टैब के नीचे स्थित ट्रेस तालिका में वही सारी जानकारी होती है जो डिवाइस पर और नेटवर्क टैब में दिखाई जाती है, लेकिन इसमें कुछ अतिरिक्त सुविधाएं भी शामिल हैं, जिनमें किसी विशिष्ट मीट्रिक के प्रतिशत परिवर्तन के आधार पर आपके ट्रेस को क्रमबद्ध करने की क्षमता शामिल है. किसी विशिष्ट ट्रेस के सभी मीट्रिक और डेटा देखने के लिए, ट्रेस तालिका में ट्रेस नाम पर क्लिक करें.
ट्रेस टेबल और मेट्रिक्स व डेटा देखने के बारे में विवरण के लिए, कंसोल अवलोकन पृष्ठ (iOS+ | Android | वेब) पर जाएं.
धीमे और रुके हुए फ़्रेमों की संख्या मेरी अपेक्षा के अनुरूप क्यों नहीं है?
धीमी रेंडरिंग फ़्रेम और फ्रोज़न फ़्रेम की गणना 60Hz की अनुमानित डिवाइस रिफ्रेश दर के साथ की जाती है. यदि किसी डिवाइस की रिफ्रेश दर 60Hz से कम है, तो प्रत्येक फ्रेम का रेंडरिंग समय धीमा होगा, क्योंकि प्रति सेकंड कम फ्रेम रेंडर किए जाते हैं.
धीमी रेंडरिंग अवधि के कारण अधिक धीमी या रुकी हुई फ्रेम की रिपोर्ट हो सकती है, क्योंकि अधिक फ्रेम धीमी गति से रेंडर किए जाएंगे या रुक जाएंगे. हालाँकि, यदि किसी डिवाइस की रिफ्रेश दर 60Hz से अधिक है, तो प्रत्येक फ्रेम का रेंडरिंग समय तेज़ होगा.
इससे कम फ़्रेम के धीमे चलने या फ़्रीज़ होने की शिकायत की जा सकती है. यह Performance Monitoring SDK में एक मौजूदा सीमा है.
मैं अपने वेब ऐप्लिकेशन में, छोटे और नेमस्पेस वाले Performance Monitoring JS SDK ("स्टैंडअलोन" SDK) को कैसे जोड़ूं?
अगर आपके ऐप्लिकेशन में सिर्फ़ Performance Monitoring Firebase प्रॉडक्ट है, तो Performance Monitoring SDK टूल का स्टैंडअलोन वर्शन इस्तेमाल किया जा सकता है. साथ ही, अगर आपको इन कामों में दिलचस्पी है, तो यहां दी गई हेडर स्क्रिप्ट का इस्तेमाल किया जा सकता है:
नेमस्पेस वाली लाइब्रेरी का इस्तेमाल करना
आपके SDK पैकेज का आकार कम करना
पेज लोड होने के बाद, एसडीके को शुरू करने में देरी करना
अपने ऐप्लिकेशन में स्टैंडअलोन Performance Monitoring SDK टूल को शामिल करने और पेज लोड होने के बाद, इसे शुरू करने के लिए:
अपनी इंडेक्स फ़ाइल के हेडर में यह स्क्रिप्ट जोड़ें.
ऊपर दी गई स्क्रिप्ट, स्टैंडअलोन SDK टूल को एसिंक्रोनस तरीके से लोड करती है. इसके बाद, विंडो के onload इवेंट के फ़ायर होने के बाद Firebase को शुरू करती है. इस रणनीति से, एसडीके का पेज लोड होने की मेट्रिक पर पड़ने वाला असर कम हो जाता है. ऐसा इसलिए होता है, क्योंकि एसडीके को शुरू करते समय ब्राउज़र पहले ही लोड होने की मेट्रिक की जानकारी दे चुका होता है.
स्टैंडअलोन Performance Monitoring SDK टूल और हेडर स्क्रिप्ट के बारे में जानें
इस स्टैंडअलोन एसडीके टूल को साइज़ के हिसाब से ऑप्टिमाइज़ किया गया है. Gzipped करने पर, यह करीब 10 केबी का होता है. इसमें Firebase Performance Monitoring की सभी सुविधाएं हैं. साथ ही, इसमें Firebase के मुख्य SDK टूल की कुछ सुविधाएं भी हैं.
Firebase Performance Monitoring, fetch और Promise एपीआई का इस्तेमाल करता है. ये एपीआई, पुराने ब्राउज़र पर उपलब्ध नहीं हैं. इन एपीआई के लिए पॉलीफ़िल, स्टैंडर्ड Firebase Performance Monitoring JS SDK में शामिल हैं. हालांकि, साइज़ कम करने के लिए इन्हें स्टैंडअलोन SDK से हटा दिया गया है.
Performance Monitoring एसडीके, ब्राउज़र से पेज लोड होने की मेट्रिक पाने के लिए, कुछ हद तक Resource Timing API पर निर्भर करता है.
नीचे दिए गए स्निपेट में, हेडर स्क्रिप्ट के बारे में बताया गया है. इसमें एसडीके के इनिशियलाइज़ेशन में देरी करने का तरीका शामिल है:
(function(sdkSource,firebaseConfigObject){functionload(f,c){//CreatesascripttagtoloadthestandaloneSDKvarsdkScript=document.createElement('script');//Setsittoanasyncscriptsothatitdoesn't interfere with page loadsdkScript.async=1;//SetsthesourceofthescriptsdkScript.src=f;//Insertsthescriptintotheheadofthepagevars=document.getElementsByTagName('script')[0];s.parentNode.insertBefore(sdkScript,s);}//Callstheloadmethodload(sdkSource);//InitializestheSDKonlywhentheonloadmethodiscalledwindow.addEventListener('load',function(){firebase.initializeApp(firebaseConfigObject).performance();});})(performance_standalone,firebaseConfig);
कहाँ,
performance_standalone'https://www.gstatic.com/firebasejs/12.6.0/firebase-performance-standalone.js' है
डेटा को करीब-करीब रीयल-टाइम में प्रोसेस और डिसप्ले करना
"करीब-करीब रीयल-टाइम" परफ़ॉर्मेंस डेटा का क्या मतलब है?
Firebase Performance Monitoring, परफ़ॉर्मेंस से जुड़े डेटा को इकट्ठा करके उसे प्रोसेस करता है. इससे Firebase कंसोल में, करीब-करीब रीयल-टाइम में डेटा दिखता है. प्रोसेस किया गया डेटा, इकट्ठा होने के कुछ ही मिनटों में कंसोल में दिखने लगता है. इसलिए, इसे "रीयल-टाइम के आस-पास" कहा जाता है.
मुझे अपने ऐप्लिकेशन के लिए, रीयल-टाइम में परफ़ॉर्मेंस का डेटा कैसे मिलेगा?
रीयल-टाइम के आस-पास डेटा प्रोसेसिंग की सुविधा का फ़ायदा लेने के लिए, आपको सिर्फ़ यह पक्का करना होगा कि आपका ऐप्लिकेशन, Performance Monitoring के ऐसे एसडीके वर्शन का इस्तेमाल करता हो जो रीयल-टाइम डेटा प्रोसेसिंग के साथ काम करता हो.
ये SDK टूल के ऐसे वर्शन हैं जो रीयल-टाइम में काम करते हैं:
iOS — v7.3.0 या इसके बाद का वर्शन
tvOS — v8.9.0 या इसके बाद का वर्शन
Android — v19.0.10 या इसके बाद का वर्शन (या Firebase Android BoM v26.1.0 या इसके बाद का वर्शन)
वेब — v7.14.0 या इसके बाद का वर्शन
ध्यान दें कि हम हमेशा एसडीके के नए वर्शन का इस्तेमाल करने का सुझाव देते हैं. हालांकि, ऊपर दिए गए किसी भी वर्शन से, Performance Monitoring को आपके डेटा को रीयल टाइम में प्रोसेस करने की सुविधा मिलेगी.
Performance Monitoring SDK के किन वर्शन को रीयल-टाइम के साथ काम करने वाला माना जाता है?
SDK टूल के ये वर्शन, रीयल-टाइम में डेटा प्रोसेस करने की सुविधा के साथ काम करते हैं:
iOS — v7.3.0 या इसके बाद का वर्शन
tvOS — v8.9.0 या इसके बाद का वर्शन
Android — v19.0.10 या इसके बाद का वर्शन (या Firebase Android BoM v26.1.0 या इसके बाद का वर्शन)
वेब — v7.14.0 या इसके बाद का वर्शन
ध्यान दें कि हम हमेशा एसडीके के नए वर्शन का इस्तेमाल करने का सुझाव देते हैं. हालांकि, ऊपर दिए गए किसी भी वर्शन से, Performance Monitoring को आपके डेटा को रीयल टाइम में प्रोसेस करने की सुविधा मिलेगी.
अगर मैंने अपने ऐप्लिकेशन को, रीयल-टाइम में काम करने वाले एसडीके के वर्शन का इस्तेमाल करने के लिए अपडेट नहीं किया, तो क्या होगा?
अगर आपका ऐप्लिकेशन, रीयल-टाइम रिपोर्टिंग की सुविधा के साथ काम करने वाले एसडीके वर्शन का इस्तेमाल नहीं करता है, तो भी आपको Firebase कंसोल में अपने ऐप्लिकेशन की परफ़ॉर्मेंस का पूरा डेटा दिखेगा. हालांकि, परफ़ॉर्मेंस डेटा दिखने में करीब 36 घंटे लगेंगे. यह समय, डेटा इकट्ठा होने के समय से शुरू होगा.
मैंने रीयल-टाइम में काम करने वाले SDK टूल के वर्शन पर अपडेट कर लिया है, लेकिन मेरे कुछ उपयोगकर्ता अब भी मेरे ऐप्लिकेशन के पुराने वर्शन इस्तेमाल कर रहे हैं. क्या मुझे Firebase कंसोल में, उनके परफ़ॉर्मेंस डेटा का ऐक्सेस मिलता रहेगा?
हां! कोई भी ऐप्लिकेशन इंस्टेंस SDK के किसी भी संस्करण का उपयोग करता हो, आपको अपने सभी उपयोगकर्ताओं का प्रदर्शन डेटा दिखाई देगा.
हालांकि, अगर आपको हाल ही का डेटा (लगभग 36 घंटे से कम पुराना) देखना है, तो दिखाया गया डेटा, ऐप्लिकेशन इंस्टेंस के उन उपयोगकर्ताओं का होता है जो रीयलटाइम के साथ काम करने वाले एसडीके वर्शन का इस्तेमाल कर रहे हैं. हालांकि, हाल ही का नहीं डेटा में, आपके ऐप्लिकेशन के सभी वर्शन का परफ़ॉर्मेंस डेटा शामिल होता है.