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