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

Firebase CLI में शामिल डेटाबेस प्रोफ़ाइलर टूल की मदद से, अपने 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 बाइट होती है. ज़्यादातर ऐप्लिकेशन के लिए, यह आपके बिल का एक छोटा सा हिस्सा होता है. हालांकि, अगर आपके मामले में बहुत ज़्यादा एसएसएल हैंडशेक की ज़रूरत है, तो यह प्रतिशत ज़्यादा हो सकता है. उदाहरण के लिए, जिन डिवाइसों पर टीएलएस सेशन टिकट काम नहीं करते हैं उन्हें बड़ी संख्या में एसएसएल कनेक्शन हैंडशेक की ज़रूरत पड़ सकती है.

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