Firebase CLI-তে বিল্ট-ইন ডেটাবেস প্রোফাইলার টুলের সাহায্যে আপনার Firebase Realtime Database-এর পারফর্ম্যান্স পরিমাপ করুন। প্রোফাইলার টুল নির্দিষ্ট সময়সীমার মধ্যে আপনার ডেটাবেসের সব অ্যাক্টিভিটি লগ করে, তারপর একটি বিস্তারিত রিপোর্ট তৈরি করে। আপনার ডেটাবেসের পারফর্ম্যান্স সংক্রান্ত সমস্যার সমাধান করতে, সমস্যাযুক্ত জায়গা চিহ্নিত করতে এবং ইন্ডেক্স না করা কোয়েরি কমাতে, বিস্তারিত রিপোর্ট ব্যবহার করুন।
প্রোফাইল তৈরি করুন
আপনার Firebase Realtime Database প্রোফাইলিং শুরু করার আগে, আপনি Firebase CLI-এর লেটেস্ট ভার্সন ব্যবহার করছেন কিনা এবং আপনি যে ডেটাবেস ও প্রোজেক্ট প্রোফাইল করতে চান তার জন্য এটি শুরু করেছেন কিনা তা নিশ্চিত করুন। মনে রাখবেন যে প্রোফাইল করার জন্য আপনাকে অবশ্যই সেই প্রোজেক্টের এডিটর বা মালিক হতে হবে।
নিম্নলিখিত কমান্ডের সাহায্যে আপনার ডেটাবেস প্রোফাইল করা শুরু করুন:
firebase database:profile
প্রোফাইল সম্পূর্ণ করতে এবং ফলাফল দেখতে Enter প্রেস করুন।
আপনার ফলাফল ব্যাখ্যা করুন
প্রোফাইলার টুল আপনার ডেটাবেসের অপারেশন সম্পর্কে সংগ্রহ করা ডেটা একত্রিত করে এবং তিনটি প্রাথমিক বিভাগে ফলাফল দেখায়: স্পিড, ব্যান্ডউইথ এবং ইনডেক্স না করা কোয়েরি।
গতি
স্পিড রিপোর্ট প্রতিটি অপারেশনের ধরনের জন্য সার্ভারের রেসপন্স টাইম (মিলিসেকেন্ডে) পরিমাপ করে। তবে, স্পিড রিপোর্টে যে স্পিড পরিমাপ করা হয় তা আসলে ব্যবহারকারীর অভিজ্ঞতার স্পিড নাও দেখাতে পারে। নেটওয়ার্কের অবস্থা সহ বিভিন্ন কারণে ক্লায়েন্টের দিকে লেটেন্সি যোগ হতে পারে।
স্পিড রিপোর্টে নিম্নলিখিত প্রপার্টি অন্তর্ভুক্ত থাকে:
- পাথ: আপনার ডেটাবেসের পাথ যেখানে অপারেশন হয়েছে। ২৫টির
বেশি চাইল্ড নোড থাকলে, প্রোফাইলার টুল এগুলিকে একটি পেরেন্ট পাথে
সংক্ষিপ্ত করে এবং একটি
$wildcardমার্কার যোগ করে। আপনি রিপোর্টে আপনার ডেটাবেসের রুট ডিরেক্টরি দেখতে পেতে পারেন, যা একটি ফরওয়ার্ড স্ল্যাশ/দ্বারা দেখানো হয়। - গণনা: প্রদত্ত পাথে হওয়া অপারেশনের সংখ্যা।
- এক্সিকিউশনের গড় স্পিড: ওই পাথে নির্দিষ্ট ধরনের অপারেশন ম্যানেজ করার জন্য প্রয়োজনীয় বিজনেস লজিক এক্সিকিউট করতে সার্ভারের যে গড় সময় লাগে। এখানে পরিমাপ করা সময়ের ব্যবধান, নিচে বর্ণিত "গড় অপেক্ষারত সময়" দ্বারা পরিমাপ করা সময়ের পরে শুরু হয়।
- গড় পেন্ডিং সময়: কার্যকর হওয়ার আগে অনুরোধগুলি গড়ে যত সময় সারিতে থাকে। ক্লায়েন্টের শুরু করা সব অনুরোধের ক্ষেত্রে এই দেরি হওয়া স্বাভাবিক। সার্ভার-সাইড অনুরোধের মোট লেটেন্সি হল সেই অনুরোধের পেন্ডিং সময় এবং এক্সিকিউশন স্পিডের যোগফল।
- অনুমতি দেওয়া হয়নি: আপনার ডেটাবেসে Firebase Database Rules-এর মাধ্যমে প্রদত্ত পাথে ব্লক করা অপারেশনের সংখ্যা।
| অপারেশনের ধরন অনুযায়ী স্পিড রিপোর্ট | |
|---|---|
| এক্সিকিউশন স্পিড পড়ুন | ডেটাবেস থেকে ডেটা পড়ার জন্য ক্লায়েন্টের অনুরোধে সার্ভার থেকে উত্তর পেতে যে সময় লাগে। রিড এক্সিকিউশন টাইম সাধারণত ডেটার পরিমাণের সাথে স্কেল করে পড়া হচ্ছে, তবে কিছু ছোট রিডও ক্যাশে দ্বারা বিলম্বিত হতে পারে প্রিফেচিং। |
| রাইট এক্সিকিউশন স্পিড | ডেটাবেসে ডেটা লেখার জন্য ক্লায়েন্টের অনুরোধে সার্ভার থেকে উত্তর পেতে যে সময় লাগে। ডেটা লেখার পরিমাণের সাথে রাইট এক্সিকিউশন টাইম স্কেল করা হয়। |
| কানেক্ট এক্সিকিউশন স্পিড | ডেটাবেস ক্লায়েন্টদের সাথে কানেকশন তৈরি করার অনুরোধের জন্য সার্ভার রেসপন্স টাইম। কানেকশন ম্যানেজমেন্টের সাথে সম্পর্কিত ইন-মেমরি সার্ভার-সাইড বুককিপিংয়ের কারণে কানেকশন অনুরোধের লেটেন্সি বেশি হয়। |
| ব্রডকাস্ট এক্সিকিউশন স্পিড | রিয়েল-টাইম আপডেটের জন্য প্রদত্ত পাথ শোনার সময় ক্লায়েন্টদের ডেটা ডিস্ট্রিবিউট করতে সার্ভারের যত সময় লাগে। ব্রডকাস্ট স্পিড রিপোর্টের Count প্রপার্টিতে কতগুলি ব্রডকাস্ট হয়েছে তার মোট সংখ্যা দেখানো হয়, কতজন ক্লায়েন্ট তথ্য পেয়েছেন তা দেখানো হয় না। যেমন, ১০ জন ক্লায়েন্ট কোনও নির্দিষ্ট পাথে শুনলে এবং সার্ভার ১০ জন ক্লায়েন্টকেই আপডেট ব্রডকাস্ট করলে, ব্রডকাস্টের সংখ্যায় মাত্র ১টি ব্রডকাস্ট দেখাবে, যদিও ১০ জন ক্লায়েন্টই ডেটা পেয়েছে। ব্রডকাস্ট স্পিড রিপোর্টে অনুমতি প্রত্যাখ্যান করা হয়েছে প্রপার্টি অন্তর্ভুক্ত করা হয়নি। |
ব্যান্ডউইথ
ব্যান্ডউইথ রিপোর্ট থেকে আপনার ডেটাবেস ইনকামিং ও আউটগোয়িং অপারেশনে কতটা ডেটা ব্যবহার করে সেই সম্পর্কে তথ্য পাওয়া যায়। তবে, বিলিংয়ের হিসেব করার জন্য আপনার ব্যান্ডউইথ রিপোর্ট ব্যবহার করা উচিত নয়, কারণ এতে অন্যান্য অপারেশনের জন্য ব্যবহৃত ব্যান্ডউইথ অন্তর্ভুক্ত থাকে না, যেমন আপনার ডেটাবেসের প্রোফাইলিং। ব্যান্ডউইথ রিপোর্ট আপনার ডেটাবেসে রিড, রাইট ও ব্রডকাস্ট অপারেশনের মাধ্যমে ব্যবহৃত ডেটার পেলোড সাইজের আনুমানিক হিসেব দেয়। এটি এমন একটি টুল যা পারফর্ম্যান্স পরিমাপ করে, বিলিংয়ের পূর্বাভাস দেয় না।
ব্যান্ডউইথ রিপোর্টে নিম্নলিখিত প্রপার্টি অন্তর্ভুক্ত থাকে:
পাথ: আপনার ডেটাবেসের পাথ যেখানে অপারেশন হয়েছে। ২৫টির বেশি চাইল্ড নোড থাকলে, প্রোফাইলার টুল এগুলিকে একটি পেরেন্ট পাথে সংক্ষিপ্ত করে।
মোট: প্রদত্ত পাথে সব অপারেশন জুড়ে ব্যবহৃত মোট আউটগোয়িং বা ইনকামিং বাইট।
গণনা: প্রদত্ত পাথে হওয়া অপারেশনের সংখ্যা।
গড়: প্রদত্ত পাথে (বাইট/রাইট বা বাইট/রিড) অপারেশন জুড়ে ডাউনলোড বা আপলোড করা বাইটের গড় সংখ্যা।
| ব্যান্ডউইথ রিপোর্ট | |
|---|---|
| ডাউনলোড করা বাইট | ক্লায়েন্ট SDK এবং REST API-এর মাধ্যমে পাঠানো রিড ও ব্রডকাস্ট অপারেশনের মাধ্যমে ডেটা ব্যবহার করা হয়। |
| আপলোড করা বাইট | ডেটাবেস সার্ভারে আসা লেখার অনুরোধের মাধ্যমে ডেটা ব্যবহার করা হয়েছে। ইনকামিংয়ের অধীনে ০ বাইট সহ রাইট হিসেবে মুছে ফেলা ডেটা দেখানো হয়। |
ইনডেক্স না করা কোয়েরি
ইনডেক্স না করা কোয়েরি ব্যয়বহুল হতে পারে, কারণ ক্লায়েন্ট কোনও লোকেশনের সব ডেটা ডাউনলোড করে এবং তারপর সেটির উপর কোয়েরি করে। এটি প্রয়োজনের চেয়ে বেশি ব্যান্ডউইথ ব্যবহার করে। আপনার ডেটাবেসের পারফর্ম্যান্স অপ্টিমাইজ করতে যতগুলি সম্ভব ইন্ডেক্স না করা কোয়েরি সমাধান করুন।
ইনডেক্স না করা কোয়েরির রিপোর্টে নিম্নলিখিত প্রপার্টি দেখা যায়:
- পাথ: আপনার ডেটাবেসের পাথ যেখানে ইন্ডেক্স না করা কোয়েরি হয়েছে।
- ইনডেক্স: ইনডেক্স না করা কোয়েরি সংক্রান্ত সমস্যার সমাধান করতে আপনাকে যে নিয়ম যোগ করতে হবে। আপনার ডেটা ইন্ডেক্স করুন বিকল্পে গিয়ে ইন্ডেক্সিং সম্পর্কে আরও জানুন।
- সংখ্যা: প্রদত্ত পাথে কতগুলি ইন্ডেক্স না করা কোয়েরি আছে।
উন্নত প্রোফাইলিং
আপনার ডেটাবেস ম্যানেজ করছে এমন সব অপারেশন দেখতে, আপনার ডেটাবেস প্রোফাইল করার সময় --raw
ফ্ল্যাগ ব্যবহার করুন, যেমন:
firebase database:profile --raw
র-আউটপুটে প্রতিটি অপারেশনের জন্য ক্লায়েন্ট তথ্যও অন্তর্ভুক্ত থাকে, যেমন
userAgent স্ট্রিং এবং IP অ্যাড্রেস। Firebase Realtime Database অপারেশনের ধরন-এ আপনার Firebase Realtime Database-এ প্রোফাইল করা বিভিন্ন অপারেশন সম্পর্কে আরও জানুন।
প্রোফাইলার টুল: এটি কোনও বিলিং টুল নয়
ব্যান্ডউইথের খরচ অনুমান করতে প্রোফাইলার টুল ব্যবহার করবেন না। প্রোফাইলার টুলটি আপনার ডেটাবেসের পারফর্ম্যান্সের একটি সামগ্রিক ছবি দেওয়ার জন্য তৈরি করা হয়েছে, যাতে আপনি অপারেশন মনিটর করতে এবং সমস্যার সমাধান করতে পারেন, বিলিং অনুমান করার জন্য নয়। এটি নেটওয়ার্ক ট্রাফিক হিসেব করে না, এটি শুধু উত্তরে পাঠানো অ্যাপ্লিকেশন ডেটার আনুমানিক হিসেব রেকর্ড করে।
Firebase-এর বিল করা নেটওয়ার্ক ট্রাফিকের কিছু সাধারণ উদাহরণ নিচে দেওয়া হল যা আপনার ডেটাবেস প্রোফাইলে কভার করা হয় না:
- প্রোটোকল ওভারহেড: সেশন তৈরি ও বজায় রাখার জন্য সার্ভার ও ক্লায়েন্টের মধ্যে কিছু অতিরিক্ত ট্রাফিক প্রয়োজন। অন্তর্নিহিত প্রোটোকলের উপর নির্ভর করে, এই ট্রাফিকের মধ্যে অন্তর্ভুক্ত থাকতে পারে: Firebase Realtime Database-এর রিয়েল-টাইম প্রোটোকল ওভারহেড, WebSocket ওভারহেড এবং HTTP হেডার ওভারহেড। প্রতিবার কানেকশন তৈরি হলে, এই ওভারহেড, যেকোনও SSL এনক্রিপশন ওভারহেডের সাথে যুক্ত হয়ে কানেকশন খরচে অবদান রাখে। যদিও এটি সাধারণত বেশি ব্যান্ডউইথ নয়, তবে আপনার পেলোড ছোট হলে অথবা আপনি ঘন ঘন, ছোট কানেকশন করলে এটি যথেষ্ট হতে পারে।
- SSL এনক্রিপশন ওভারহেড: সুরক্ষিত কানেকশনের জন্য প্রয়োজনীয় SSL এনক্রিপশন ওভারহেডের সাথে খরচ যুক্ত থাকে। গড়ে, এই খরচ প্রাথমিক হ্যান্ডশেকের জন্য প্রায় ৩.৫KB এবং প্রতিটি আউটগোয়িং মেসেজে TLS রেকর্ড হেডারের জন্য প্রায় ৪০B। বেশিরভাগ অ্যাপের ক্ষেত্রে, এটি আপনার বিলের একটি ছোট শতাংশ। তবে, আপনার নির্দিষ্ট কেসে অনেক SSL হ্যান্ডশেক প্রয়োজন হলে, এটি একটি বড় শতাংশ হতে পারে। যেমন, TLS সেশন টিকিট কাজ করে না এমন ডিভাইসে SSL কানেকশন হ্যান্ডশেক করার জন্য অনেক বেশি সংখ্যক কানেকশন প্রয়োজন হতে পারে।
আপনার বিল বোঝা ও অনুমান করা সম্পর্কে আরও পড়ুন।