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

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

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

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

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

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

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

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

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

अगर आपको अपने ऐप्लिकेशन में SDK टूल का नया वर्शन जोड़े हुए 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 को शामिल नहीं करते, क्योंकि पेज के रिस्पॉन्स में लगने वाला समय (आईएनपी) ने क्लिक के बाद रिस्पॉन्स में लगा समय (एफ़आईडी) की जगह ले ली है.

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

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

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

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

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

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 सर्वर-साइड सैंपलिंग का इस्तेमाल कर सकता है. इससे डिवाइसों से मिले कुछ इवेंट को हटाया जा सकता है. इस तरह की सीमा से हमारी मेट्रिक के असर पर कोई असर नहीं पड़ता. हालांकि, इससे पैटर्न में मामूली बदलाव हो सकते हैं. इनमें ये शामिल हैं:

  • ट्रेस की संख्या, कोड के किसी हिस्से को लागू किए जाने की संख्या से अलग हो सकती है.
  • कोड में एक-दूसरे से जुड़े हुए ट्रेस में, सैंपल की संख्या अलग-अलग हो सकती है.

Console में समस्याएं टैब का क्या हुआ?

हमने समस्याओं वाले टैब को हटाकर, सूचनाओं की सुविधा जोड़ी है. इससे, आपके सेट किए गए थ्रेशोल्ड के पार होने पर आपको अपने-आप सूचना मिलती है. अब आपको थ्रेशोल्ड की स्थिति देखने के लिए, 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/13.1.0/firebase-performance.js' है
• firebaseConfig आपके ऐप्लिकेशन का Firebase कॉन्फ़िगरेशन ऑब्जेक्ट है

ऊपर दी गई स्क्रिप्ट, स्टैंडअलोन SDK टूल को एसिंक्रोनस तरीके से लोड करती है. इसके बाद, विंडो का 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 टूल के ऐसे वर्शन का इस्तेमाल करता हो जो रीयल-टाइम डेटा प्रोसेसिंग के साथ काम करता हो.

SDK टूल के ये वर्शन, रीयल-टाइम में काम करते हैं:

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

ध्यान दें कि हम हमेशा SDK टूल के नए वर्शन का इस्तेमाल करने का सुझाव देते हैं. हालांकि, ऊपर दिए गए किसी भी वर्शन का इस्तेमाल करने पर, 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 या इसके बाद का वर्शन

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

अगर मैं अपने ऐप्लिकेशन को रीयल-टाइम में काम करने वाले एसडीके वर्शन पर अपडेट न करूं, तो क्या होगा?

अगर आपका ऐप्लिकेशन, रीयल-टाइम में काम करने वाले एसडीके वर्शन का इस्तेमाल नहीं करता है, तो भी आपको Firebase कंसोल में अपने ऐप्लिकेशन की परफ़ॉर्मेंस का पूरा डेटा दिखेगा. हालांकि, परफ़ॉर्मेंस डेटा इकट्ठा होने के करीब 36 घंटे बाद ही दिखेगा.

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

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

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

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

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

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

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