परफ़ॉर्मेंस मॉनिटर करने से जुड़ी समस्या हल करना और अक्सर पूछे जाने वाले सवाल

परफ़ॉर्मेंस इवेंट के लिए लॉग मैसेज देखने का तरीका

1. अपने ब्राउज़र के डेवलपर टूल खोलें. उदाहरण के लिए, Chrome डेवलपर टूल के लिए नेटवर्क टैब या Firefox के लिए नेटवर्क मॉनिटर.

2. ब्राउज़र में अपने वेब ऐप्लिकेशन को रीफ़्रेश करें.

3. गड़बड़ी के मैसेज के लिए, अपने लॉग मैसेज देखें.

4. कुछ सेकंड बाद, अपने ब्राउज़र के डेवलपर टूल में firebaselogging.googleapis.com पर नेटवर्क कॉल देखें. इस नेटवर्क कॉल से पता चलता है कि ब्राउज़र, परफ़ॉर्मेंस का डेटा Firebase को भेज रहा है.

अगर आपका ऐप्लिकेशन परफ़ॉर्मेंस इवेंट लॉग नहीं कर रहा है, तो समस्या हल करने के सुझाव देखें.

ऐप्लिकेशन में एसडीके टूल जोड़ा गया है, लेकिन कंसोल में अब भी एसडीके टूल जोड़ने का मैसेज दिख रहा है

जब Firebase को आपके ऐप्लिकेशन से इवेंट की जानकारी (जैसे, ऐप्लिकेशन के साथ इंटरैक्शन) मिलती है, तब वह यह पता लगा सकता है कि आपने अपने ऐप्लिकेशन में Performance Monitoring SDK टूल को सही तरीके से जोड़ा है या नहीं. आम तौर पर, ऐप्लिकेशन शुरू करने के 10 मिनट के अंदर, Firebase कंसोल के परफ़ॉर्मेंस डैशबोर्ड पर "एसडीके टूल का पता चला" मैसेज दिखता है. इसके बाद, 30 मिनट के अंदर डैशबोर्ड पर प्रोसेस किया गया शुरुआती डेटा दिखता है.

अगर आपने अपने ऐप्लिकेशन में एसडीके का नया वर्शन जोड़े हुए 10 मिनट से ज़्यादा हो गए हैं और आपको अब भी कोई बदलाव नहीं दिख रहा है, तो अपने लॉग मैसेज देखें. इससे यह पक्का किया जा सकेगा कि Performance Monitoring इवेंट लॉग कर रहा है. एसडीके का पता लगाने में देरी होने पर दिखने वाले मैसेज से जुड़ी समस्या हल करने के लिए, यहां बताया गया तरीका आज़माएं.

Console में यह दिखता है कि SDK टूल का पता चल गया है, लेकिन कोई डेटा नहीं दिखता

Performance Monitoring परफ़ॉर्मेंस इवेंट डेटा को प्रोसेस करता है. इसके बाद, इसे परफ़ॉर्मेंस डैशबोर्ड में दिखाता है.

अगर "SDK का पता चला" मैसेज दिखने के 24 घंटे से ज़्यादा समय बीत चुका है और आपको अब भी डेटा नहीं दिख रहा है, तो Firebase के स्टेटस डैशबोर्ड पर जाकर देखें कि क्या कोई ज्ञात समस्या है. अगर कोई समस्या नहीं है, तो Firebase की सहायता टीम से संपर्क करें.

ऐप्लिकेशन, परफ़ॉर्मेंस इवेंट लॉग नहीं कर रहा है

अगर आपको परफ़ॉर्मेंस इवेंट के लिए लॉग मैसेज नहीं दिख रहे हैं, तो समस्या हल करने के लिए यह तरीका आज़माएं:

1. पक्का करें कि आपके ऐप्लिकेशन में Performance Monitoring SDK टूल को सही तरीके से शुरू किया गया हो.

2. पक्का करें कि Performance Monitoring SDK को इस फ़्लैग के ज़रिए बंद न किया गया हो:

   • performance.instrumentationEnabled

3. पक्का करें कि आपके ब्राउज़र में कैश मेमोरी की सुविधा बंद हो. ऐसा न होने पर, ब्राउज़र नई इंस्ट्रुमेंटेशन सेटिंग को शायद न पहचान पाए.

4. वेबपेज टैब को बंद करें और फिर से खोलें. फिर से लॉग इन करके देखें.

   अगर आपने अभी-अभी अपने ऐप्लिकेशन में Performance Monitoring SDK जोड़ा है, तो हो सकता है कि आपको अपने ऐप्लिकेशन को पूरी तरह से रीस्टार्ट करना पड़े, ताकि SDK काम करना शुरू कर दे.

5. अगर आपको अपने ऐप्लिकेशन में कोई भी सुविधा बंद नहीं दिखती है, तो Firebase की सहायता टीम से संपर्क करें.

परफ़ॉर्मेंस डैशबोर्ड में, पहले इनपुट में लगने वाले समय का डेटा मौजूद नहीं है

मॉडर्न ऐप्लिकेशन में _fid को शामिल नहीं किया जाता है, क्योंकि पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) ने क्लिक के बाद रिस्पॉन्स में लगा समय (एफ़आईडी) की जगह ले ली है.

पुराने ब्राउज़र में FID रिकॉर्ड करने के लिए:

1. लेगसी FID पॉलीफ़िल जोड़ें.

2. पुष्टि करें कि उपयोगकर्ता, पेज लोड होने के पांच सेकंड के अंदर उससे इंटरैक्ट करता है. Performance Monitoring इस विंडो के दौरान ही FID रिकॉर्ड करता है.

परफ़ॉर्मेंस डैशबोर्ड में कस्टम ट्रेस डेटा मौजूद नहीं है

क्या आपको अपने-आप इकट्ठा किए गए ट्रेस के लिए परफ़ॉर्मेंस डेटा दिख रहा है, लेकिन कस्टम कोड ट्रेस के लिए नहीं? समस्या हल करने के लिए, यह तरीका आज़माएं:

1. Trace API की मदद से लागू किए गए कस्टम कोड ट्रेस के सेटअप की जांच करें. खास तौर पर, इनकी जांच करें:

   • कस्टम कोड ट्रेस और कस्टम मेट्रिक के नाम इन ज़रूरी शर्तों को पूरा करते हों: नाम की शुरुआत या आखिर में कोई खाली जगह न हो, नाम की शुरुआत में अंडरस्कोर (_) वर्ण न हो, और नाम की ज़्यादा से ज़्यादा लंबाई 32 वर्ण हो.
   • सभी ट्रेस शुरू और बंद किए जाने चाहिए. शुरू नहीं किए गए, बंद नहीं किए गए या शुरू होने से पहले बंद किए गए किसी भी ट्रेस को लॉग नहीं किया जाएगा.

   ध्यान दें कि अगर record() तरीके का इस्तेमाल किया जा रहा है, तो आपको ट्रेस को साफ़ तौर पर शुरू या बंद करने की ज़रूरत नहीं है.

2. पक्का करें कि Performance Monitoring डेटा कलेक्शन की सुविधा, बंद न हो. इसके लिए, यह फ़्लैग इस्तेमाल करें:

   • performance.dataCollectionEnabled

     यह फ़्लैग, सिर्फ़ कस्टम कोड ट्रेस के लिए डेटा कलेक्शन को कंट्रोल करता है. यह सभी डेटा को कंट्रोल नहीं करता.

3. अपने लॉग मैसेज देखें, ताकि यह पक्का किया जा सके कि Performance Monitoring, उम्मीद के मुताबिक कस्टम कोड ट्रेस लॉग कर रहा है.

4. अगर Performance Monitoring इवेंट लॉग कर रहा है, लेकिन 24 घंटे बाद भी कोई डेटा नहीं दिखता है, तो Firebase की सहायता टीम से संपर्क करें.

परफ़ॉर्मेंस डैशबोर्ड में नेटवर्क अनुरोध का डेटा मौजूद नहीं है

अगर आपको नेटवर्क अनुरोध का डेटा नहीं दिख रहा है, तो इन बातों का ध्यान रखें:

• Performance Monitoring, ब्राउज़र एपीआई से रिपोर्ट किए गए नेटवर्क अनुरोधों के लिए मेट्रिक अपने-आप इकट्ठा करता है. इन रिपोर्ट में, नेटवर्क के ऐसे अनुरोध शामिल नहीं होते जिन्हें पूरा नहीं किया जा सका.

• आपके कोड और कोड में इस्तेमाल की गई नेटवर्किंग लाइब्रेरी के व्यवहार के आधार पर, Performance Monitoring सिर्फ़ उन नेटवर्क अनुरोधों की रिपोर्ट दे सकता है जो पूरे हो चुके हैं. इसका मतलब है कि खुले हुए एचटीटीपी/एचटीटीपीएस कनेक्शन की रिपोर्ट नहीं की जा सकती.

नेटवर्क के अनुरोध से जुड़े डेटा को उम्मीद के मुताबिक एग्रीगेट नहीं किया जा रहा है

यूआरएल पैटर्न के तहत, Performance Monitoring नेटवर्क अनुरोध के डेटा को कैसे एग्रीगेट करता है, इस बारे में ज़्यादा जानें.

कस्टम यूआरएल के पैटर्न भी आज़माए जा सकते हैं!

प्रोजेक्ट होम पेज पर मौजूद परफ़ॉर्मेंस कार्ड में, सबसे ज़्यादा बार आने वाली समस्याओं का क्या हुआ?

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

परफ़ॉर्मेंस कार्ड में सबसे ऊपर मौजूद ऐप्लिकेशन चुनने वाले टूल की मदद से, हाल की सूचनाएं में मौजूद सूचनाओं को फ़िल्टर किया जा सकता है. चुने गए ऐप्लिकेशन के लिए, सिर्फ़ तीन सबसे हाल की चेतावनियां दिखाई जाती हैं.

सूचनाओं के बारे में ज़्यादा जानने के लिए, परफ़ॉर्मेंस से जुड़ी समस्याओं के लिए सूचनाएं सेट अप करना लेख पढ़ें.

कंसोल में समस्याओं के लिए थ्रेशोल्ड सेट करने की सुविधा का क्या हुआ?

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 | वेब).

ज़्यादा समय लेने वाले और फ़्रीज़ हुए फ़्रेम की संख्या, मेरी उम्मीद के मुताबिक क्यों नहीं है?

धीमी रेंडरिंग फ़्रेम और रुके हुए फ़्रेम का हिसाब, डिवाइस के रीफ़्रेश रेट के आधार पर लगाया जाता है. इसके लिए, 60 हर्ट्ज़ का रीफ़्रेश रेट माना जाता है. अगर किसी डिवाइस का रीफ़्रेश रेट 60 हर्ट्ज़ से कम है, तो हर फ़्रेम को रेंडर होने में ज़्यादा समय लगेगा. ऐसा इसलिए, क्योंकि हर सेकंड में कम फ़्रेम रेंडर होते हैं. रेंडर होने में ज़्यादा समय लगने की वजह से, रेंडर होने में बहुत ज़्यादा समय लेने वाले फ़्रेम या फ़्रीज़ होने वाले फ़्रेम की ज़्यादा शिकायतें मिल सकती हैं. ऐसा इसलिए, क्योंकि ज़्यादा फ़्रेम धीरे-धीरे रेंडर होंगे या फ़्रीज़ हो जाएंगे. हालांकि, अगर डिवाइस का रीफ़्रेश रेट 60 हर्ट्ज़ से ज़्यादा है, तो हर फ़्रेम को रेंडर होने में कम समय लगेगा. इस वजह से, कम फ़्रेम के धीमे चलने या फ़्रीज़ होने की शिकायत की जा सकती है. Performance Monitoring SDK टूल में फ़िलहाल यह समस्या आ रही है.

मैं अपने वेब ऐप्लिकेशन में, छोटे और नेमस्पेस वाले Performance Monitoring JS SDK ("स्टैंडअलोन" SDK) को कैसे जोड़ूं?

अगर आपके ऐप्लिकेशन में सिर्फ़ Performance Monitoring Firebase प्रॉडक्ट है, तो Performance Monitoring के स्टैंडअलोन SDK टूल का इस्तेमाल किया जा सकता है. साथ ही, अगर आपको इन चीज़ों में दिलचस्पी है, तो यहां दी गई हेडर स्क्रिप्ट का इस्तेमाल किया जा सकता है:

• नेमस्पेस वाली लाइब्रेरी का इस्तेमाल करना
• एसडीके पैकेज का साइज़ कम करना
• पेज लोड होने के बाद, एसडीके को शुरू करने में देरी करना

अपने ऐप्लिकेशन में स्टैंडअलोन Performance Monitoring SDK टूल को शामिल करने और पेज लोड होने के बाद, इसे शुरू करने के लिए:

1. अपनी इंडेक्स फ़ाइल के हेडर में यह स्क्रिप्ट जोड़ें.
2. अपने ऐप्लिकेशन का Firebase प्रोजेक्ट कॉन्फ़िगरेशन ऑब्जेक्ट जोड़ना न भूलें.

(function(sa,fbc){function load(f,c){var a=document.createElement('script');
a.async=1;a.src=f;var s=document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(a,s);}load(sa);
window.addEventListener('load',function(){firebase.initializeApp(fbc).performance()});
})(performance_standalone, firebaseConfig);

कहाँ,

• performance_standalone 'https://www.gstatic.com/firebasejs/12.19.0/firebase-performance.js' है
• firebaseConfig आपके ऐप्लिकेशन का Firebase कॉन्फ़िगरेशन ऑब्जेक्ट है

ऊपर दी गई स्क्रिप्ट, स्टैंडअलोन एसडीके को एसिंक्रोनस तरीके से लोड करती है. इसके बाद, विंडो के onload इवेंट के ट्रिगर होने के बाद Firebase को शुरू करती है. इस तरीके से, एसडीके टूल का पेज लोड होने की मेट्रिक पर पड़ने वाला असर कम हो जाता है. ऐसा इसलिए होता है, क्योंकि एसडीके टूल को शुरू करते समय ब्राउज़र पहले ही लोड होने की मेट्रिक की जानकारी दे चुका होता है.

(function(sdkSource, firebaseConfigObject) {
   function load(f, c) {
       // Creates a script tag to load the standalone SDK
       var sdkScript = document.createElement('script');

       // Sets it to an async script so that it doesn't interfere with page load
       sdkScript.async = 1;

       // Sets the source of the script
       sdkScript.src = f;

       // Inserts the script into the head of the page
       var s = document.getElementsByTagName('script')[0];
       s.parentNode.insertBefore(sdkScript, s);
   }

   // Calls the load method
   load(sdkSource);

   // Initializes the SDK only when the onload method is called
   window.addEventListener('load', function() {
       firebase.initializeApp(firebaseConfigObject).performance();
   });
})(performance_standalone, firebaseConfig);

कितने कस्टम यूआरएल पैटर्न बनाए जा सकते हैं?

हर ऐप्लिकेशन के लिए, ज़्यादा से ज़्यादा 400 कस्टम यूआरएल पैटर्न बनाए जा सकते हैं. साथ ही, उस ऐप्लिकेशन के हर डोमेन के लिए, ज़्यादा से ज़्यादा 100 कस्टम यूआरएल पैटर्न बनाए जा सकते हैं.

"करीब-करीब रीयल-टाइम" परफ़ॉर्मेंस डेटा का क्या मतलब है?

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 के किन वर्शन को रीयल-टाइम के साथ काम करने वाला माना जाता है?

रीयल-टाइम में डेटा प्रोसेस करने की सुविधा के साथ काम करने वाले एसडीके के वर्शन ये हैं:

• 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 घंटे बाद ही, उसे दिखाया जाएगा.

मैंने रीयल-टाइम में काम करने वाले एसडीके वर्शन पर अपडेट कर लिया है, लेकिन मेरे कुछ उपयोगकर्ता अब भी मेरे ऐप्लिकेशन के पुराने वर्शन इस्तेमाल कर रहे हैं. क्या मुझे Firebase कंसोल में उनकी परफ़ॉर्मेंस का डेटा दिखता रहेगा?

हां! ऐप्लिकेशन का कोई इंस्टेंस, एसडीके के जिस भी वर्शन का इस्तेमाल करता है उससे कोई फ़र्क़ नहीं पड़ता. आपको अपने सभी उपयोगकर्ताओं का परफ़ॉर्मेंस डेटा दिखेगा.

हालांकि, अगर आपको हाल ही का डेटा (लगभग 36 घंटे से कम पुराना) देखना है, तो दिखाया गया डेटा, ऐप्लिकेशन इंस्टेंस के उन उपयोगकर्ताओं का होता है जो रीयल-टाइम के साथ काम करने वाले एसडीके वर्शन का इस्तेमाल कर रहे हैं. हालांकि, हाल ही का नहीं डेटा में, आपके ऐप्लिकेशन के सभी वर्शन का परफ़ॉर्मेंस डेटा शामिल होता है.

मुझे परफ़ॉर्मेंस डेटा का रीयल टाइम डिसप्ले क्यों नहीं दिख रहा है?

रीयल टाइम में परफ़ॉर्मेंस का डेटा देखने के लिए, पक्का करें कि आपका ऐप्लिकेशन, Performance Monitoring एसडीके के ऐसे वर्शन का इस्तेमाल करता हो जो रीयल टाइम में डेटा प्रोसेस करने के साथ काम करता हो.

• iOS — v7.3.0 या इसके बाद का वर्शन
• tvOS — v8.9.0 या उसके बाद का वर्शन
• Android — v19.0.10 या इसके बाद का वर्शन (या Firebase Android BoM v26.1.0 या इसके बाद का वर्शन)
• वेब — v7.14.0 या इसके बाद का वर्शन

ध्यान दें कि हम हमेशा एसडीके के सबसे नए वर्शन का इस्तेमाल करने का सुझाव देते हैं. हालांकि, ऊपर दिए गए किसी भी वर्शन का इस्तेमाल करके, Performance Monitoring को आपके डेटा को रीयल टाइम में प्रोसेस करने की अनुमति दी जा सकती है.