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