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