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