Firebase CLI में पहले से मौजूद डेटाबेस प्रोफ़ाइलर टूल की मदद से, अपने Firebase Realtime Database की परफ़ॉर्मेंस का आकलन करें. प्रोफ़ाइलर टूल, किसी तय समयावधि के दौरान आपके डेटाबेस में हुई सभी गतिविधियों को लॉग करता है. इसके बाद, वह पूरी जानकारी वाली रिपोर्ट जनरेट करता है. अपने डेटाबेस की परफ़ॉर्मेंस से जुड़ी समस्याओं को हल करने, समस्याओं का पता लगाने, और इंडेक्स नहीं की गई क्वेरी को कम करने के लिए, ज़्यादा जानकारी वाली रिपोर्ट का इस्तेमाल करें.
प्रोफ़ाइल बनाना
Firebase Realtime Database की प्रोफ़ाइलिंग शुरू करने से पहले, पक्का करें कि आपने Firebase सीएलआई का सबसे नया वर्शन इस्तेमाल किया हो. साथ ही, आपने उस डेटाबेस और प्रोजेक्ट के लिए इसे शुरू किया हो जिसकी आपको प्रोफ़ाइलिंग करनी है. ध्यान दें कि प्रोफ़ाइल के लिए, आपके पास उस प्रोजेक्ट का एडिटर या मालिक होना ज़रूरी है.
नीचे दिए गए कमांड की मदद से अपने डेटाबेस की प्रोफ़ाइल बनाना शुरू करें:
firebase database:profile
प्रोफ़ाइल को पूरा करने और नतीजे दिखाने के लिए, Enter दबाएं.
अपने नतीजों को समझना
प्रोफ़ाइलर टूल, आपके डेटाबेस के ऑपरेशन के बारे में इकट्ठा किया गया डेटा इकट्ठा करता है और नतीजों को तीन मुख्य कैटगरी में दिखाता है: स्पीड, बैंडविड्थ, और बिना इंडेक्स की गई क्वेरी.
स्पीड
साइट लोड होने की रफ़्तार बताने वाली रिपोर्ट में, हर तरह के ऑपरेशन के लिए, सर्वर से जवाब मिलने में लगने वाला समय (मिलीसेकंड में) मेज़र किया जाता है. हालांकि, हो सकता है कि स्पीड रिपोर्ट में मापी गई स्पीड, असल में असली उपयोगकर्ताओं के अनुभव की जानकारी न दे. नेटवर्क की स्थिति के साथ-साथ कई अन्य वजहों से, क्लाइंट साइड पर इंतज़ार का समय बढ़ सकता है.
स्पीड रिपोर्ट में ये प्रॉपर्टी शामिल होती हैं:
- पाथ: आपके डेटाबेस में वह पाथ जहां कार्रवाइयां हुईं. अगर 25 से ज़्यादा चाइल्ड नोड हैं, तो प्रोफ़ाइलर टूल उन्हें पैरंट पाथ में छोटा कर देता है और
$wildcardमार्कर जोड़ देता है. आपको रिपोर्ट में अपने डेटाबेस की रूट डायरेक्ट्री दिख सकती है. इसे फ़ॉरवर्ड स्लैश/से दिखाया जाता है. - काउंट: दिए गए पाथ पर हुई कार्रवाइयों की संख्या.
- कार्रवाई पूरी होने में लगने वाला औसत समय: सर्वर को उस पाथ पर किसी खास तरह की कार्रवाई को मैनेज करने के लिए, ज़रूरी बिज़नेस लॉजिक को लागू करने में लगने वाला औसत समय. यहां मेज़र किया गया समय अंतराल शुरू हो जाता है. इसके बाद, उसे यहां दिए गए "औसत समय" की मदद से मेज़र किया जाता है.
- पूरे होने में लगने वाला औसत समय: अनुरोधों को पूरा होने में लगने वाला औसत समय. क्लाइंट से शुरू किए गए सभी अनुरोधों में यह देरी आम तौर पर होती है. सर्वर साइड से अनुरोध करने में लगने वाला कुल समय, करीब-करीब उस अनुरोध के बाकी बचे समय और उस पर लगने वाले समय का कुल योग होता है.
- अनुमति नहीं दी गई: दिए गए पाथ पर की गई उन कार्रवाइयों की संख्या जिन्हें आपके डेटाबेस में, Firebase डेटाबेस के नियमों से ब्लॉक किया गया था.
| ऑपरेशन टाइप के हिसाब से साइट लोड होने की रफ़्तार की रिपोर्ट | |
|---|---|
| रीड एक्सीक्यूशन स्पीड | डेटाबेस का डेटा पढ़ने के लिए, क्लाइंट के अनुरोध पर सर्वर से जवाब मिलने में लगने वाला समय. आम तौर पर, डेटा पढ़ने में लगने वाला समय, पढ़े जा रहे डेटा के हिसाब से तय होता है. हालांकि, कैश मेमोरी में डेटा को पहले से लोड करने की वजह से, कुछ छोटी रीड में भी देरी हो सकती है. |
| Write Execution Speed | डेटाबेस में डेटा लिखने के लिए, क्लाइंट के अनुरोधों का जवाब देने में सर्वर को लगने वाला समय. लिखे जा रहे डेटा की संख्या के हिसाब से, एक्सीक्यूशन के समय के स्केल लिखें. |
| कनेक्ट करने की स्पीड | डेटाबेस क्लाइंट के अनुरोधों को स्थापित करने के लिए सर्वर प्रतिक्रिया समय. कनेक्शन के अनुरोधों के लिए इंतज़ार का समय, कनेक्शन मैनेजमेंट से जुड़ी इन-मेमोरी सर्वर-साइड रिकवरी पर निर्भर करता है. |
| ब्रॉडकास्ट की प्रोसेसिंग में लगने वाला समय | रीयलटाइम अपडेट के लिए दिए गए पाथ को सुनने वाले क्लाइंट को डेटा डिस्ट्रिब्यूट करने में सर्वर को लगने वाला समय. ब्रॉडकास्ट की स्पीड की रिपोर्ट में मौजूद Count प्रॉपर्टी, ब्रॉडकास्ट की संख्या को इकट्ठा करती है, न कि जानकारी पाने वाले क्लाइंट की संख्या को. उदाहरण के लिए, अगर किसी पाथ पर 10 क्लाइंट सुन रहे थे और सर्वर ने सभी 10 क्लाइंट को अपडेट ब्रॉडकास्ट किया, तो ब्रॉडकास्ट की संख्या सिर्फ़ एक ब्रॉडकास्ट दिखाती है. भले ही, 10 क्लाइंट को डेटा मिल गया हो. अनुमति नहीं दी गई प्रॉपर्टी को ब्रॉडकास्ट की स्पीड की रिपोर्ट में शामिल नहीं किया जाता. |
बैंडविड्थ
बैंडविथ रिपोर्ट से यह अहम जानकारी मिलती है कि आपका डेटाबेस, इनकमिंग और आउटगोइंग ऑपरेशन के दौरान कितना डेटा खर्च करता है. हालांकि, बिलिंग का अनुमान लगाने के लिए, आपको बैंडविड्थ रिपोर्ट का इस्तेमाल नहीं करना चाहिए. ऐसा इसलिए, क्योंकि इसमें अन्य ऑपरेशन के लिए इस्तेमाल किए गए बैंडविड्थ को शामिल नहीं किया जाता. जैसे, आपके डेटाबेस की प्रोफ़ाइल बनाना. बैंडविड्थ रिपोर्ट से, आपके डेटाबेस में डेटा को पढ़ने, लिखने, और ब्रॉडकास्ट करने के लिए इस्तेमाल किए गए डेटा के पेलोड साइज़ का अनुमान लगाया जाता है. यह एक ऐसा टूल है जो परफ़ॉर्मेंस का आकलन करता है, न कि बिलिंग का अनुमान लगाता है.
बैंडविड्थ रिपोर्ट में ये प्रॉपर्टी शामिल होती हैं:
पाथ: आपके डेटाबेस में वह पाथ जहां कार्रवाइयां हुईं. अगर 25 से ज़्यादा चाइल्ड नोड हैं, तो प्रोफ़ाइलर टूल उन्हें पैरंट पाथ में छोटा कर देता है.
कुल: दिए गए पाथ पर सभी ऑपरेशन में इस्तेमाल किए गए आउटगोइंग या इनकमिंग बाइट की कुल संख्या.
गिनती: दिए गए पाथ पर हुए ऑपरेशन की संख्या.
औसत: दिए गए पाथ पर, सभी ऑपरेशन के लिए डाउनलोड या अपलोड किए गए बाइट की औसत संख्या (बाइट/लिखें या बाइट/रीड).
| बैंडविथ रिपोर्ट | |
|---|---|
| डाउनलोड किए गए बाइट | क्लाइंट SDK और REST API के ज़रिए भेजे गए, पढ़ने और ब्रॉडकास्ट करने के ऑपरेशन से इस्तेमाल किया गया डेटा. |
| अपलोड की गई बाइट | डेटाबेस सर्वर में आने वाले लिखने के अनुरोधों के ज़रिए खर्च किया गया डेटा. हटाए गए आइटम को 0 बाइट के साथ लिखा जाता है के तौर पर दिखाया जाता है. |
इंडेक्स नहीं की गई क्वेरी
इंडेक्स नहीं की गई क्वेरी की लागत ज़्यादा हो सकती है, क्योंकि क्लाइंट किसी जगह पर मौजूद सारा डेटा डाउनलोड करते हैं और फिर उस पर क्वेरी करते हैं. इससे ज़रूरत से ज़्यादा बैंडविड्थ का इस्तेमाल होता है. अपने डेटाबेस की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, इंडेक्स नहीं की गई ज़्यादा से ज़्यादा क्वेरी को ठीक करें.
इंडेक्स नहीं की गई क्वेरी रिपोर्ट में ये प्रॉपर्टी दिखती हैं:
- पाथ: आपके डेटाबेस में वह पाथ जहां इंडेक्स नहीं की गई क्वेरी हुईं.
- इंडेक्स करें: यह वह नियम है जिसे इंडेक्स नहीं की गई क्वेरी को हल करने के लिए जोड़ना चाहिए. अपना डेटा इंडेक्स करें में, इंडेक्स करने के बारे में ज़्यादा जानें.
- गिनती: दिए गए पाथ पर, इंडेक्स नहीं की गई क्वेरी की संख्या.
बेहतर प्रोफ़ाइलिंग
डेटाबेस में होने वाले सभी ऑपरेशन देखने के लिए, डेटाबेस की प्रोफ़ाइल बनाते समय --raw
फ़्लैग का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:
firebase database:profile --raw
रॉ आउटपुट में हर ऑपरेशन के लिए क्लाइंट की जानकारी भी शामिल होती है. जैसे, userAgent स्ट्रिंग और आईपी पते. Firebase Realtime Database ऑपरेशन टाइप में अपने Firebase Realtime Database में की गई अलग-अलग कार्रवाइयों के बारे में ज़्यादा जानें.
प्रोफ़ाइलर टूल: यह बिलिंग टूल नहीं है
बैंडविड्थ की लागत का अनुमान लगाने के लिए, प्रोफ़ाइलर टूल का इस्तेमाल न करें. प्रोफ़ाइलर टूल का मकसद आपको डेटाबेस की परफ़ॉर्मेंस की पूरी जानकारी देना है. इससे आपको ऑपरेशन की निगरानी करने और समस्याओं को हल करने में मदद मिलती है, न कि बिलिंग का अनुमान लगाने में. इसमें नेटवर्क ट्रैफ़िक को शामिल नहीं किया जाता. यह सिर्फ़ जवाबों में भेजे गए ऐप्लिकेशन डेटा का अनुमान रिकॉर्ड करता है.
Firebase के ज़रिए बिल किए गए नेटवर्क ट्रैफ़िक के कुछ सामान्य उदाहरण यहां दिए गए हैं. ये ट्रैफ़िक आपकी डेटाबेस प्रोफ़ाइल में शामिल नहीं होते:
- प्रोटोकॉल ओवरहेड: सेशन शुरू करने और उसे बनाए रखने के लिए, सर्वर और क्लाइंट के बीच कुछ अतिरिक्त ट्रैफ़िक ज़रूरी होता है. इस्तेमाल किए जा रहे प्रोटोकॉल के आधार पर, इस ट्रैफ़िक में ये शामिल हो सकते हैं: Firebase रीयलटाइम डेटाबेस का रीयलटाइम प्रोटोकॉल ओवरहेड, वेबसोकेट ओवरहेड, और एचटीटीपी हेडर ओवरहेड. हर बार कनेक्शन बनने पर, इस ओवरहेड के साथ-साथ एसएसएल एन्क्रिप्शन के ओवरहेड की वजह से, कनेक्शन की लागत बढ़ जाती है. आम तौर पर, यह ज़्यादा बैंडविड्थ नहीं होती. हालांकि, अगर आपके पेलोड छोटे हैं या अक्सर छोटे कनेक्शन किए जाते हैं, तो यह ज़्यादा हो सकती है.
- एसएसएल एन्क्रिप्शन ओवरहेड: सुरक्षित कनेक्शन के लिए, एसएसएल एन्क्रिप्शन ओवरहेड की ज़रूरत होती है. इसकी लागत होती है. औसतन, शुरुआती हैंडशेक के लिए यह लागत करीब 3.5 केबी है और हर आउटगोइंग मैसेज के लिए TLS रिकॉर्ड हेडर के लिए करीब 40 अरब है. ज़्यादातर ऐप्लिकेशन के लिए, यह आपके बिल का एक छोटा हिस्सा होता है. हालांकि, अगर आपके मामले में बहुत सारे एसएसएल हैंडशेक की ज़रूरत है, तो यह प्रतिशत ज़्यादा हो सकता है. उदाहरण के लिए, जिन डिवाइसों पर टीएलएस सेशन के टिकट काम नहीं करते उन्हें बहुत सारे एसएसएल कनेक्शन हैंडशेक की ज़रूरत पड़ सकती है.
अपने बिल को समझने और उसका अनुमान लगाने के बारे में ज़्यादा पढ़ें.