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

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

1. डीबग लॉगिंग की सुविधा चालू करें. इसके लिए, यह तरीका अपनाएं:

   1. Xcode (कम से कम v26.2) में, Product > Scheme > Edit scheme को चुनें.
   2. बाईं ओर मौजूद मेन्यू से, Run को चुनें. इसके बाद, Arguments टैब को चुनें.
   3. Arguments Passed on Launch सेक्शन में, -FIRDebugEnabled जोड़ें.

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

3. Performance Monitoring अपने लॉग मैसेज को Firebase/Performance से टैग करता है, ताकि लॉग मैसेज को फ़िल्टर किया जा सके.

4. नीचे दिए गए लॉग टाइप देखें. इनसे पता चलता है कि Performance Monitoring, परफ़ॉर्मेंस इवेंट लॉग कर रहा है या नहीं:

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. Firebase कंसोल में अपना डेटा देखने के लिए, यूआरएल पर क्लिक करें. डैशबोर्ड में डेटा अपडेट होने में कुछ समय लग सकता है.

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

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

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

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

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

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

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

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

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

1. पक्का करें कि आपकी Info.plist फ़ाइल में, इनमें से किसी भी फ़्लैग के ज़रिए Performance Monitoring SDK को बंद न किया गया हो:

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

2. पक्का करें कि रनटाइम के दौरान Performance Monitoring बंद न हो (Swift | Obj-C).

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

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

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

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

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

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

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

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

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

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

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

1. देखें कि नेटवर्क लाइब्रेरी, आपके डिवाइस के साथ काम करती है या नहीं. Performance Monitoring नेटवर्क अनुरोधों के लिए मेट्रिक अपने-आप इकट्ठा करता है. ये अनुरोध, नेटवर्किंग की इन लाइब्रेरी का इस्तेमाल करते हैं:

   • Swift के लिए: URLSession और URLConnection
   • Objective-C के लिए: NSURLSession और NSURLConnection

   ध्यान दें कि आपके पास नेटवर्क अनुरोधों के लिए, कस्टम मॉनिटरिंग जोड़ने का विकल्प होता है.

2. इन बातों का ध्यान रखें:

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

   • Performance Monitoring, अमान्य Content-Type हेडर वाले नेटवर्क अनुरोधों की रिपोर्ट नहीं करता. हालांकि, Content-Type हेडर के बिना किए गए नेटवर्क अनुरोध अब भी स्वीकार किए जाएंगे.

नेटवर्क के अनुरोध का डेटा, उम्मीद के मुताबिक इकट्ठा नहीं हो रहा है

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

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

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

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

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

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

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

Performance Monitoring, तय की गई सीमा से ज़्यादा होने वाली मेट्रिक के लिए सूचनाएं पाने की सुविधा देता है. परफ़ॉर्मेंस मेट्रिक के लिए कॉन्फ़िगर किए जा सकने वाले इन थ्रेशोल्ड की वजह से होने वाले भ्रम को दूर करने के लिए, हमने समस्याओं के लिए थ्रेशोल्ड कॉन्फ़िगर करने की सुविधा हटा दी है.

Firebase कंसोल में मौजूद, जानकारी और मेट्रिक सेक्शन में क्या कोई बदलाव हुआ है?

हमने समस्याओं को हल करने के तरीके को बेहतर बनाने के लिए, 'जानकारी' और 'मेट्रिक' पेजों को नए सिरे से डिज़ाइन किए गए, केंद्रीकृत यूज़र इंटरफ़ेस (यूआई) से बदल दिया है. समस्या हल करने वाले इस नए यूज़र इंटरफ़ेस (यूआई) में, वही मुख्य सुविधाएं मिलती हैं जो 'जानकारी' और 'मेट्रिक' सेक्शन में मिलती थीं. समस्या हल करने के बारे में ज़्यादा जानने के लिए, किसी खास ट्रेस के लिए ज़्यादा डेटा देखना लेख पढ़ें.

सैंपल की संख्या मेरी उम्मीद के मुताबिक क्यों नहीं है?

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

हम जो डेटा इकट्ठा करते हैं उसकी मात्रा को मैनेज करने के लिए, Performance Monitoring इन सैंपलिंग विकल्पों का इस्तेमाल करता है:

• डिवाइस पर दर सीमित करना: किसी डिवाइस को अचानक कई ट्रेस भेजने से रोकने के लिए, हम किसी डिवाइस से भेजे गए कोड और नेटवर्क अनुरोध ट्रेस की संख्या को हर 10 मिनट में 300 इवेंट तक सीमित कर देते हैं. इस तरीके से, डिवाइस को लूप की गई इंस्ट्रूमेंटेशन से सुरक्षित रखा जाता है. इससे परफ़ॉर्मेंस का ज़्यादा डेटा भेजा जा सकता है. साथ ही, यह किसी एक डिवाइस को परफ़ॉर्मेंस मेज़रमेंट को गलत तरीके से दिखाने से रोकता है.

• डाइनैमिक सैंपलिंग: Performance Monitoring हर दिन, ऐप्लिकेशन के सभी उपयोगकर्ताओं के लिए, ऐप्लिकेशन के हिसाब से कोड ट्रेस और नेटवर्क अनुरोध ट्रेस की सीमित संख्या इकट्ठा करता है. डिवाइसों पर डाइनैमिक सैंपलिंग रेट (Firebase Remote Config का इस्तेमाल करके) फ़ेच किया जाता है. इससे यह तय किया जाता है कि किसी रैंडम डिवाइस को ट्रेस कैप्चर करके भेजना चाहिए या नहीं. सैंपलिंग के लिए नहीं चुना गया डिवाइस, कोई भी इवेंट नहीं भेजता है. डाइनैमिक सैंपलिंग रेट, ऐप्लिकेशन के हिसाब से तय होता है. यह इस तरह से अडजस्ट होता है कि इकट्ठा किए गए डेटा का कुल वॉल्यूम, तय सीमा से कम रहे.

  जिन प्रोजेक्ट में BigQuery इंटिग्रेशन की सुविधा चालू है उन्हें नेटवर्क अनुरोधों के ट्रेस की संख्या के लिए ज़्यादा सीमा मिलती है.

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

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

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

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

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

कंसोल में डिवाइस पर और नेटवर्क टैब का क्या हुआ? मैं उन पेजों पर मौजूद ट्रेस कैसे देखूं?

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

डैशबोर्ड टैब में सबसे नीचे मौजूद ट्रेस टेबल में, वही सारी जानकारी होती है जो डिवाइस पर और नेटवर्क टैब में दिखती है. हालांकि, इसमें कुछ और सुविधाएं भी जोड़ी गई हैं. जैसे, किसी खास मेट्रिक के लिए प्रतिशत में हुए बदलाव के हिसाब से, अपने ट्रेस को क्रम से लगाने की सुविधा. किसी खास ट्रेस के लिए, सभी मेट्रिक और डेटा देखने के लिए, ट्रेस टेबल में ट्रेस के नाम पर क्लिक करें.

ट्रेस टेबल के इन सब-टैब में अपने ट्रेस देखें:

• नेटवर्क अनुरोध ट्रेस (दोनों, बॉक्स से बाहर और कस्टम) — नेटवर्क अनुरोध सबटैब
• कस्टम कोड ट्रेस — कस्टम ट्रेस सब-टैब
• ऐप्लिकेशन शुरू होने, ऐप्लिकेशन के फ़ोरग्राउंड में होने, और ऐप्लिकेशन के बैकग्राउंड में होने के ट्रेस — कस्टम ट्रेस सबटैब
• स्क्रीन रेंडरिंग ट्रेस — स्क्रीन रेंडरिंग सब-टैब
• पेज लोड ट्रेस — पेज लोड सब-टैब

ट्रेस टेबल और मेट्रिक और डेटा देखने के बारे में जानकारी के लिए, कंसोल के खास जानकारी वाले पेज पर जाएं (iOS+ | Android | वेब).

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

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

मेरे Performance Monitoring डेटा को BigQuery में एक्सपोर्ट होने में, उम्मीद से ज़्यादा समय लग रहा है. क्या यह रीयल टाइम में नहीं दिखता है?

अगर आपने Firebase Performance Monitoring के लिए BigQuery इंटिग्रेशन चालू किया है, तो आपका डेटा दिन खत्म होने के 12 से 24 घंटे बाद (पैसिफ़िक समय) BigQuery में एक्सपोर्ट किया जाएगा.

उदाहरण के लिए, 19 अप्रैल का डेटा, BigQuery में 20 अप्रैल को दोपहर 12 बजे से आधी रात के बीच उपलब्ध होगा. सभी तारीखें और समय, पैसिफ़िक समय के हिसाब से हैं.

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

हर ऐप्लिकेशन के लिए, ज़्यादा से ज़्यादा 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 को आपके डेटा को रीयल टाइम में प्रोसेस करने की अनुमति दी जा सकती है.