अपने डेटाबेस की प्रोफ़ाइल बनाएं

Firebase सीएलआई में मौजूद डेटाबेस प्रोफ़ाइलर टूल की मदद से, अपने Firebase Realtime Database की परफ़ॉर्मेंस का आकलन करें. प्रोफ़ाइलर टूल, किसी तय समयावधि के दौरान आपके डेटाबेस में होने वाली सभी गतिविधियों को लॉग करता है. इसके बाद, वह एक ज़्यादा जानकारी वाली रिपोर्ट जनरेट करता है. ज़्यादा जानकारी वाली रिपोर्ट का इस्तेमाल करके, अपने डेटाबेस की परफ़ॉर्मेंस से जुड़ी समस्याएं हल करें. साथ ही, समस्या वाले हिस्सों का पता लगाएं और इंडेक्स नहीं की गई क्वेरी की संख्या कम करें.

प्रोफ़ाइल बनाना

1. अपने Firebase Realtime Database की प्रोफ़ाइल बनाने से पहले, पक्का करें कि आपके पास Firebase सीएलआई का नया वर्शन हो. साथ ही, आपने इसे उस डेटाबेस और प्रोजेक्ट के लिए शुरू किया हो जिसकी प्रोफ़ाइल बनानी है. ध्यान दें कि प्रोफ़ाइल बनाने के लिए, आपके पास उस प्रोजेक्ट का मालिकाना हक होना चाहिए या आप उसके एडिटर हों.

2. अपने डेटाबेस की प्रोफ़ाइल बनाने के लिए, यह कमांड इस्तेमाल करें:

   firebase database:profile

   प्रोफ़ाइलर, आपके डेटाबेस से कार्रवाइयों को रिकॉर्ड करने और प्रोफ़ाइल बनाने के दौरान, स्टेटस मैसेज दिखाता है.

3. प्रोफ़ाइल पूरी करने और नतीजे देखने के लिए, Enter दबाएं.

अपने नतीजों को समझना

प्रोफ़ाइलर टूल, आपके डेटाबेस के ऑपरेशन के बारे में इकट्ठा किए गए डेटा को एग्रीगेट करता है. साथ ही, नतीजों को तीन मुख्य कैटगरी में दिखाता है: स्पीड, बैंडविड्थ, और इंडेक्स नहीं की गई क्वेरी.

स्पीड

स्पीड रिपोर्ट, हर तरह की कार्रवाई के लिए सर्वर के रिस्पॉन्स टाइम (मिलीसेकंड में) को मेज़र करती है. हालांकि, स्पीड रिपोर्ट में मेज़र की गई स्पीड, शायद असली उपयोगकर्ताओं को मिलने वाली स्पीड से अलग हो. नेटवर्क की स्थिति जैसी कई वजहों से, क्लाइंट साइड पर इंतज़ार का समय बढ़ सकता है.

स्पीड रिपोर्ट में ये प्रॉपर्टी शामिल होती हैं:

• पाथ: आपके डेटाबेस का वह पाथ जहां कार्रवाइयां की गईं. अगर 25 से ज़्यादा चाइल्ड नोड हैं, तो प्रोफ़ाइलर टूल उन्हें पैरंट पाथ में छोटा कर देता है और $wildcard मार्कर जोड़ देता है. आपको रिपोर्ट में अपने डेटाबेस की रूट डायरेक्ट्री दिख सकती है. इसे फ़ॉरवर्ड स्लैश / से दिखाया जाता है.
• संख्या: दिए गए पाथ पर हुई कार्रवाइयों की संख्या.
• कार्रवाई पूरी होने में लगने वाला औसत समय: सर्वर को उस पाथ पर किसी खास तरह की कार्रवाई को पूरा करने के लिए, कारोबारी नियम को लागू करने में लगने वाला औसत समय. यहां मेज़र किया गया समय अंतराल, "औसत" के हिसाब से मेज़र किए गए समय के बाद शुरू होता है नीचे बताया गया "मंज़ूरी बाकी रहने का समय".
• अनुरोधों को प्रोसेस होने में लगने वाला औसत समय: अनुरोधों को प्रोसेस होने से पहले, सूची में रहने में लगने वाला औसत समय. क्लाइंट की ओर से किए गए सभी अनुरोधों में यह देरी आम है. सर्वर-साइड पर अनुरोध में लगने वाला कुल समय, उस अनुरोध के लिए इंतज़ार करने में लगने वाले समय और उसे पूरा करने में लगने वाले समय का जोड़ होता है.
• अनुमति नहीं दी गई: आपके डेटाबेस पर, Firebase डेटाबेस के नियमों की वजह से, दिए गए पाथ पर ब्लॉक किए गए ऑपरेशन की संख्या.

बैंडविड्थ

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

बैंडविड्थ रिपोर्ट में ये प्रॉपर्टी शामिल होती हैं:

• पाथ: आपके डेटाबेस का वह पाथ जहां कार्रवाइयां की गईं. अगर 25 से ज़्यादा चाइल्ड नोड हैं, तो प्रोफ़ाइलर टूल उन्हें पैरंट पाथ में छोटा कर देता है.

• कुल: दिए गए पाथ पर सभी कार्रवाइयों में इस्तेमाल किए गए कुल आउटगोइंग या इनकमिंग बाइट.

• संख्या: दिए गए पाथ पर हुई कार्रवाइयों की संख्या.

• औसत: दिए गए पाथ पर, ऑपरेशन के दौरान डाउनलोड या अपलोड किए गए बाइट की औसत संख्या (बाइट/राइट या बाइट/रीड).

इंडेक्स नहीं की गई क्वेरी

बिना इंडेक्स की गई क्वेरी महंगी हो सकती हैं, क्योंकि क्लाइंट किसी जगह का पूरा डेटा डाउनलोड करते हैं और फिर उस पर क्वेरी करते हैं. इससे ज़रूरत से ज़्यादा बैंडविड्थ का इस्तेमाल होता है. अपने डेटाबेस की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, इंडेक्स नहीं की गई ज़्यादा से ज़्यादा क्वेरी को हल करें.

इंडेक्स नहीं की गई क्वेरी की रिपोर्ट में ये प्रॉपर्टी दिखती हैं:

• पाथ: आपके डेटाबेस में वह पाथ जहां इंडेक्स नहीं की गई क्वेरी मौजूद हैं.
• इंडेक्स: इंडेक्स नहीं की गई क्वेरी की समस्या को हल करने के लिए, आपको यह नियम जोड़ना चाहिए. अपने डेटा को इंडेक्स करें में जाकर, इंडेक्स करने के बारे में ज़्यादा जानें.
• संख्या: दिए गए पाथ पर मौजूद, इंडेक्स नहीं की गई क्वेरी की संख्या.

ऐडवांस प्रोफ़ाइलिंग

अपने डेटाबेस की प्रोफ़ाइल बनाते समय, --raw फ़्लैग का इस्तेमाल करके, अपने डेटाबेस से मैनेज किए जा रहे सभी ऑपरेशन देखें. इसके लिए, यह तरीका अपनाएं:

firebase database:profile --raw

रॉ आउटपुट में, हर कार्रवाई के लिए क्लाइंट की जानकारी भी शामिल होती है. जैसे, userAgent स्ट्रिंग और आईपी पते. Firebase Realtime Database ऑपरेशन टाइप में, Firebase Realtime Database में प्रोफ़ाइल किए गए अलग-अलग ऑपरेशन के बारे में ज़्यादा जानें.

प्रोफ़ाइलर टूल: यह बिलिंग टूल नहीं है

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

यहां नेटवर्क ट्रैफ़िक के कुछ ऐसे उदाहरण दिए गए हैं जिनके लिए Firebase आपसे शुल्क लेता है. हालांकि, ये आपकी डेटाबेस प्रोफ़ाइल में शामिल नहीं होते:

• प्रोटोकॉल ओवरहेड: सेशन को शुरू करने और उसे बनाए रखने के लिए, सर्वर और क्लाइंट के बीच कुछ अतिरिक्त ट्रैफ़िक ज़रूरी होता है. अंडरलाइंग प्रोटोकॉल के आधार पर, इस ट्रैफ़िक में ये शामिल हो सकते हैं: Firebase रीयलटाइम डेटाबेस का रीयलटाइम प्रोटोकॉल ओवरहेड, WebSocket ओवरहेड, और एचटीटीपी हेडर ओवरहेड. हर बार कनेक्शन बनने पर, यह ओवरहेड और एसएसएल एन्क्रिप्शन ओवरहेड, कनेक्शन की लागत में जुड़ जाता है. आम तौर पर, यह बैंडविड्थ ज़्यादा नहीं होती है. हालांकि, अगर आपके पेलोड छोटे हैं या बार-बार छोटे कनेक्शन बनाए जाते हैं, तो यह बैंडविड्थ ज़्यादा हो सकती है.
• एसएसएल एन्क्रिप्शन ओवरहेड: सुरक्षित कनेक्शन के लिए ज़रूरी एसएसएल एन्क्रिप्शन ओवरहेड से जुड़ी लागत होती है. औसत के तौर पर, शुरुआती हैंडशेक के लिए यह लागत करीब 3.5 केबी होती है. साथ ही, जाने वाले हर मैसेज पर टीएलएस रिकॉर्ड हेडर के लिए यह लागत करीब 40 बाइट होती है. ज़्यादातर ऐप्लिकेशन के लिए, यह आपके बिल का एक छोटा हिस्सा होता है. हालांकि, अगर आपके मामले में बहुत सारे एसएसएल हैंडशेक की ज़रूरत है, तो यह प्रतिशत ज़्यादा हो सकता है. उदाहरण के लिए, जिन डिवाइसों पर टीएलएस सेशन टिकट काम नहीं करते उन्हें एसएसएल कनेक्शन हैंडशेक की ज़रूरत पड़ सकती है.

अपने बिल को समझने और उसका अनुमान लगाने के बारे में ज़्यादा जानें.