Firebase Performance: এটি কী, মেট্রিক্স এবং কীভাবে ট্র্যাক করবেন

Firebase Performance Monitoring কী

Firebase Performance Monitoring একটি SDK এবং ক্লাউড প্ল্যাটফর্ম যা মোবাইল অ্যাপ পারফরম্যান্স মেট্রিক্স সংগ্রহ, একত্রিত এবং ভিজুয়ালাইজ করে। SDK অ্যাপে এমবেড হয় এবং স্বয়ংক্রিয়ভাবে মূল পয়েন্টগুলি ইন্সট্রুমেন্ট করে: Activity লাইফসাইকেল (Android) বা ViewController (iOS), URLSession (iOS) বা OkHttp (Android) এর মাধ্যমে নেটওয়ার্ক রিকোয়েস্ট এবং সিস্টেম কল। সংগৃহীত ডেটা Firebase সার্ভারে পাঠানো হয়, যেখানে এটি অ্যাপ সংস্করণ, ডিভাইস, দেশ এবং অন্যান্য বৈশিষ্ট্য অনুসারে একত্রিত হয়।

Performance SDK আর্কিটেকচার ন্যূনতম ওভারহেড নীতিতে নির্মিত: ইন্সট্রুমেন্টেশন পরিমাপকৃত অপারেশনের সম্পাদন সময়ে 1–2% এর বেশি যোগ করে না। ডেটা অ্যাসিঙ্ক্রোনাসভাবে সংগ্রহ করা হয় এবং পাঠানোর আগে ডিভাইসে বাফার করা হয়, যা UI থ্রেড পারফরম্যান্সের উপর কোন প্রভাব দূর করে। ডেটা একটি সময়সূচিতে পাঠানো হয় (ডিফল্টভাবে প্রতি 30 মিনিটে) অথবা যখন বাফার 100 KB এ পৌঁছায়।

Firebase Performance এবং Android Studio প্রোফাইলার (CPU Profiler) বা Xcode Instruments-এর মধ্যে মূল পার্থক্য হল উৎপাদন মনিটরিং। Firebase Performance শুধু ডেভেলপার ডিভাইস থেকে নয়, বাস্তব ব্যবহারকারী ডিভাইস থেকে ডেটা সংগ্রহ করে। এটি নির্দিষ্ট মডেল, OS সংস্করণ বা নির্দিষ্ট অঞ্চলে ঘটে যাওয়া সমস্যাগুলি সনাক্ত করতে দেয় — এমন সমস্যা যা নিয়ন্ত্রিত পরিবেশে পুনরুত্পাদন করা যায় না।

কোড পরিবর্তন ছাড়া SDK কীভাবে ডেটা সংগ্রহ করে

স্বয়ংক্রিয় ইন্সট্রুমেন্টেশন Firebase Performance-এর প্রধান বৈশিষ্ট্য। Android-এর জন্য, SDK স্বয়ংক্রিয়ভাবে ActivityLifecycleCallbacks নিবন্ধন করে এবং onCreate এবং onResume-এর মধ্যে সময় (স্ক্রিন রেন্ডারিং টাইম) পরিমাপ করে। iOS-এর জন্য, এটি viewDidLoad এবং viewDidAppear পদ্ধতি সুইজল করে। নেটওয়ার্ক রিকোয়েস্ট OkHttpInterceptor (Android) বা NSURLProtocol (iOS) স্তরে আটকানো হয়। ডেভেলপারকে স্ট্যান্ডার্ড মেট্রিক্সের জন্য start/stop কল যোগ করার প্রয়োজন নেই।

Performance SDK সক্ষম এবং নিষ্ক্রিয় করা Google Services প্লাগইন (Android) বা Info.plist (iOS) এর মাধ্যমে পরিচালিত হয়। ডিবাগিংয়ের জন্য, আপনি Performance SDK-এর ভার্বোজ লগিং সক্ষম করতে পারেন, যা দেখায় কোন মেট্রিক্স সংগ্রহ এবং পাঠানো হচ্ছে। প্রোডাকশনে, অপ্রয়োজনীয় তথ্য দিয়ে লগ জমা এড়াতে সতর্কতা স্তরে লগিং রাখার পরামর্শ দেওয়া হয়। Flutter বা React Native-এর প্রকল্পগুলির জন্য, স্বয়ংক্রিয় ইন্সট্রুমেন্টেশন সীমিত হতে পারে — কোড উদাহরণ বিভাগে আরও বিস্তারিত।

বিনামূল্যের সীমা এবং মূল্য নির্ধারণ

Firebase Performance বিনামূল্যের Spark টিয়ারে ট্রেস বা ডেটা ভলিউমের সংখ্যার কোন সীমা ছাড়াই উপলব্ধ। পরিশোধিত Blaze টিয়ারও Performance Monitoring-এর জন্য চার্জ নেয় না — এটি কয়েকটি Firebase সার্ভিসের মধ্যে একটি যা উভয় টিয়ারে সম্পূর্ণ বিনামূল্যে। শুধুমাত্র একটি সীমাবদ্ধতা আছে: ডেটা 30 দিন (Spark-এ) এবং 365 দিন পর্যন্ত (Blaze-এ) সংরক্ষণ করা হয়। দীর্ঘমেয়াদী বিশ্লেষণের জন্য, BigQuery export-এর মাধ্যমে ডেটা রপ্তানি করুন।

কোন খরচ নেই Firebase Performance-কে যেকোনো প্রকল্পের জন্য একটি আদর্শ পছন্দ করে তোলে — প্রোটোটাইপ থেকে লক্ষ লক্ষ ব্যবহারকারীর এন্টারপ্রাইজ অ্যাপ্লিকেশন পর্যন্ত। একমাত্র খরচ হল Performance SDK-এর আউٹগোয়িং ট্রাফিক, কিন্তু এটি অ্যাপের অন্যান্য নেটওয়ার্ক অপারেশনের তুলনায় নগণ্য (প্রতি ডিভাইসে প্রতি মাসে 1 MB এর কম)। BigQuery export স্টোরেজ এবং কোয়েরির জন্য চার্জ নেয়, কিন্তু Performance SDK নিজেই বিনামূল্যে।

স্বয়ংক্রিয় মেট্রিক্স: কোড ছাড়া কী পরিমাপ করা হয়

Firebase Performance একটি লাইন কোড ছাড়াই পাঁচটি বিভাগের মেট্রিক্স স্বয়ংক্রিয়ভাবে সংগ্রহ করে: অ্যাপ স্টার্টআপ টাইম, ধীর HTTP রিকোয়েস্ট, স্ক্রিন রেন্ডারিং গতি, মেমরি ব্যবহার (শুধু Android) এবং ফ্রেম রেট (শুধু Android)। SDK সংযোগ এবং প্রথম ব্যবহারকারী সেশনের পরপরই এই মেট্রিক্স Firebase কনসোলে উপলব্ধ হয়।

অ্যাপ স্টার্টআপ টাইম — প্রক্রিয়া শুরু থেকে ইন্টারঅ্যাকশনের জন্য UI-এর সম্পূর্ণ প্রস্তুতি পর্যন্ত সময়। এটি কোল্ড স্টার্ট (অ্যাপ স্ক্র্যাচ থেকে শুরু) এবং ওয়ার্ম স্টার্ট (অ্যাপ ব্যাকগ্রাউন্ড অবস্থা থেকে পুনরায় শুরু) এ বিভক্ত। কোল্ড স্টার্টে DEX ফাইল লোড করা, স্ট্যাটিক ফিল্ড ইনিশিয়ালাইজ করা, Application.onCreate এবং Activity.onCreate কল করা অন্তর্ভুক্ত। Firebase স্বয়ংক্রিয়ভাবে স্টার্ট টাইপ শ্রেণীবদ্ধ করে এবং প্রতিটি প্রকারের জন্য সময় বিতরণ দেখায়।

স্ক্রিন রেন্ডারিং টাইম — স্ক্রিন লোডিং শুরু (Android-এর জন্য onCreate, iOS-এর জন্য viewDidLoad) থেকে ইন্টারঅ্যাকশনের জন্য স্ক্রিন প্রস্তুত হওয়ার মুহূর্ত (onResume, viewDidAppear) পর্যন্ত সময়। Firebase প্রতিটি স্ক্রিন (শ্রেণির নাম বা কাস্টম স্ক্রিন নাম দ্বারা) অনুসারে ডেটা একত্রিত করে, যা কোন স্ক্রিন সবচেয়ে বেশি সময় নেয় তা সনাক্ত করতে দেয়। Android-এর জন্য, ড্রপ করা ফ্রেমও পরিমাপ করা হয় — স্ক্রিন রেন্ডারিংয়ের সময় বাদ দেওয়া ফ্রেমের সংখ্যা (jank)।

নেটওয়ার্ক রিকোয়েস্ট (HTTP/HTTPS)

Performance SDK URLSession, OkHttp বা URLConnection-এর মাধ্যমে অ্যাপ থেকে পাঠানো প্রতিটি HTTP/HTTPS রিকোয়েস্ট স্বয়ংক্রিয়ভাবে আটকায় এবং পরিমাপ করে। প্রতিটি রিকোয়েস্টের জন্য নিম্নলিখিতগুলি রেকর্ড করা হয়: URL (নিরাপত্তার জন্য কোয়েরি প্যারামিটার ছাড়া পাথ), HTTP পদ্ধতি, প্রতিক্রিয়া কোড, বাইটে প্রতিক্রিয়া আকার, রিকোয়েস্টের সময়কাল এবং সংযোগ গতি (WiFi, Cellular)। ডেটা Firebase কনসোলের নেটওয়ার্ক রিকোয়েস্ট ড্যাশবোর্ডে একত্রিত হয়।

ধীর রিকোয়েস্ট — এমন রিকোয়েস্ট যার সময়কাল নির্ধারিত সীমা অতিক্রম করে। ডিফল্টভাবে, ধীর রিকোয়েস্টের সীমা 4000 ms। এই মেট্রিক ব্যাকএন্ড সমস্যা সনাক্ত করার জন্য গুরুত্বপূর্ণ: যদি ব্যাকএন্ড আপডেটের পর ধীর রিকোয়েস্টের সংখ্যা 1% থেকে 15% এ বেড়ে যায়, এটি তাৎক্ষণিক সার্ভার লগ বিশ্লেষণের সংকেত। ব্যবহারকারীরা প্রতিক্রিয়ার জন্য 5 সেকেন্ডের বেশি অপেক্ষা করবে না — Firebase ডেটা দেখায় যে 53% ব্যবহারকারী অ্যাপ বন্ধ করে দেয় যদি একটি রিকোয়েস্ট 3 সেকেন্ডের বেশি সময় নেয়।

স্বয়ংক্রিয় ইন্সট্রুমেন্টেশনের সীমাবদ্ধতা

iOS সীমাবদ্ধতা: iOS-এ, Performance SDK ড্রপ করা ফ্রেম পরিমাপ করতে পারে না (এটি একটি প্রাইভেট API)। iOS-এ jank পরিমাপ করতে MetricKit বা CADisplayLink ব্যবহার করুন। এছাড়াও, iOS-এ, SDK তৃতীয় পক্ষের HTTP ক্লায়েন্টের মাধ্যমে করা রিকোয়েস্ট আটকায় না যা URLSession ব্যবহার করে না (যেমন SwiftNIO)। এই ধরনের ক্ষেত্রে, HTTP বৈশিষ্ট্য সহ কাস্টম ট্রেস ব্যবহার করুন।

Android সীমাবদ্ধতা: Android-এ, স্বয়ংক্রিয় মেমরি পরিমাপ শুধুমাত্র Android 8.0+ (API 26+) ডিভাইসে উপলব্ধ। পুরানো সংস্করণের জন্য, Debug.getMemoryInfo()-এর মাধ্যমে প্রাপ্ত ডেটা সহ কাস্টম ট্রেস ব্যবহার করুন। এছাড়াও, SDK WebSocket সংযোগ আটকায় না — সেগুলির জন্য পৃথক ট্রেস প্রয়োজন। এই সীমাবদ্ধতা সত্ত্বেও, স্বয়ংক্রিয় মেট্রিক্স 80% পারফরম্যান্স মনিটরিং প্রয়োজনীয়তা পূরণ করে।

কাস্টম ট্রেস এবং HTTP বৈশিষ্ট্য

কাস্টম ট্রেস হল নামযুক্ত সময় ব্যবধান যা ডেভেলপার নির্দিষ্ট পরিস্থিতির পারফরম্যান্স পরিমাপের জন্য ম্যানুয়ালি তৈরি করে: নিউজ ফিড লোড করা, ইমেজ প্রসেস করা, ডেটা সিঙ্ক্রোনাইজ করা, জটিল ডাটাবেস কোয়েরি সম্পাদন করা। কাস্টম ট্রেস স্বয়ংক্রিয় মেট্রিক্সের পরিপূরক এবং কোডের সেই অংশগুলি পরিমাপ করতে দেয় যা ডেভেলপার পারফরম্যান্সের জন্য গুরুত্বপূর্ণ মনে করে।

প্রতিটি ট্রেসের একটি নাম (সর্বোচ্চ 100 অক্ষর) থাকে এবং এতে 5টি পর্যন্ত কাস্টম মেট্রিক্স থাকতে পারে — ট্রেসের ভিতরে রেকর্ড করা সংখ্যাসূচক মান। উদাহরণস্বরূপ, একটি "image_processing" ট্রেসে, আপনি "original_file_size" এবং "processed_file_size"-এর মতো মেট্রিক্স পরিমাপ করতে পারেন। মেট্রিক্স Firebase কনসোলে বিতরণ হিসাবে প্রদর্শিত হয় (সর্বনিম্ন, সর্বোচ্চ, গড়, শতকরা), যা শুধু সময়কাল নয়, অপারেশন বৈশিষ্ট্যও বিশ্লেষণ করতে দেয়।

HTTP বৈশিষ্ট্য — নেটওয়ার্ক রিকোয়েস্টের জন্য এক বিশেষ ধরনের কাস্টম ট্রেস যা SDK দ্বারা স্বয়ংক্রিয়ভাবে আটকানো হয়নি (যেমন WebSocket বা তৃতীয় পক্ষের লাইব্রেরির মাধ্যমে)। HTTP বৈশিষ্ট্যগুলির মধ্যে URL, HTTP পদ্ধতি, প্রতিক্রিয়া কোড এবং প্রতিক্রিয়া আকার অন্তর্ভুক্ত। Firebase সেগুলি স্বয়ংক্রিয়ভাবে সংগৃহীত রিকোয়েস্টের সাথে নেটওয়ার্ক রিকোয়েস্ট বিভাগে প্রদর্শন করে, নেটওয়ার্ক মিথস্ক্রিয়ার একটি ঐক্যবদ্ধ চিত্র প্রদান করে।

কখন কাস্টম ট্রেস ব্যবহার করবেন

কাস্টম ট্রেস পরিমাপের জন্য অপরিহার্য: স্থানীয় ডাটাবেস (Room, CoreData) থেকে ডেটা লোড করার সময়, জটিল গণনার সময়কাল (এনক্রিপশন, কম্প্রেশন), অ্যানিমেশন এবং ট্রানজিশন পারফরম্যান্স, তৃতীয় পক্ষের SDK (মানচিত্র, পেমেন্ট, বিশ্লেষণ) এর প্রতিক্রিয়া সময়। এই ধরনের প্রতিটি পরিস্থিতির জন্য, একটি ট্রেস তৈরি করুন, পরিমাপকৃত কোড start/stop-এ মোড়ান এবং পরবর্তী বিভাজনের জন্য বৈশিষ্ট্য যোগ করুন।

কাস্টম ট্রেসের অপব্যবহার করবেন না। প্রতিটি ট্রেস ব্যাটারি এবং ট্রাফিক ওভারহেড যোগ করে। প্রোডাকশন সংস্করণে 10–15টির বেশি সক্রিয় ট্রেস না রাখার পরামর্শ দেওয়া হয়। ডিবাগিংয়ের জন্য, আপনি আরও ট্রেস যোগ করতে পারেন, কিন্তু রিলিজের আগে, Remote Config-এর মাধ্যমে অতিরিক্ত ট্রেস নিষ্ক্রিয় করুন (performance_tracing_enabled ফ্ল্যাগ ব্যবহার করুন)। এটি শুধুমাত্র নির্বাচিত ব্যবহারকারী বা সেশনের জন্য বিস্তারিত ট্রেসিং সক্ষম করতে দেয়।

বিভাজনের জন্য ট্রেস বৈশিষ্ট্য

কাস্টম বৈশিষ্ট্য হল কী-মান জোড়া যা Firebase কনসোলে পরবর্তী ফিল্টারিংয়ের জন্য ট্রেসে যোগ করা যেতে পারে। উদাহরণস্বরূপ, "feed_load" ট্রেসের জন্য, আপনি "feed_type" (main, explore, following) এবং "cache_status" (cold, warm)-এর মতো বৈশিষ্ট্য যোগ করতে পারেন। কনসোলে, ট্রেস ডেটা এই বৈশিষ্ট্য দ্বারা ফিল্টার করা যেতে পারে কোন ফিডের ধরন সবচেয়ে ধীরে লোড হয় তা নির্ধারণ করতে।

সীমাবদ্ধতা: প্রতিটি ট্রেসে 5টি পর্যন্ত কাস্টম বৈশিষ্ট্য থাকতে পারে। বৈশিষ্ট্যের মান 100 অক্ষর পর্যন্ত স্ট্রিং। ট্রেস শুরু হওয়ার আগে বৈশিষ্ট্য নির্ধারণ করতে হবে; শুরুর পরে বৈশিষ্ট্য পরিবর্তন উপেক্ষা করা হয়। এই সীমাবদ্ধতা পারফরম্যান্সের সাথে সম্পর্কিত: শুরুর পরে বৈশিষ্ট্য স্থির করতে অতিরিক্ত সিঙ্ক্রোনাইজেশন প্রয়োজন হবে।

পারফরম্যান্স থ্রেশহোল্ড এবং সতর্কতা

থ্রেশহোল্ড হল মেট্রিক্সের জন্য কনফিগারযোগ্য সীমা মান, যা অতিক্রম করলে Firebase Performance একটি সতর্কতা তৈরি করে। প্রতিটি স্বয়ংক্রিয় মেট্রিকের জন্য Firebase কনসোলে (Performance > Thresholds) থ্রেশহোল্ড নির্ধারণ করা হয়: অ্যাপ স্টার্টআপ টাইম (কোল্ড/ওয়ার্ম), স্ক্রিন রেন্ডারিং টাইম, ধীর HTTP রিকোয়েস্ট, HTTP প্রতিক্রিয়া সময়। আপনি সব অ্যাপ সংস্করণের জন্য বৈশ্বিক থ্রেশহোল্ড বা নির্দিষ্ট সংস্করণের জন্য নির্দিষ্ট থ্রেশহোল্ড নির্ধারণ করতে পারেন।

সতর্কতা হল স্বয়ংক্রিয় বিজ্ঞপ্তি যা Firebase একটি থ্রেশহোল্ড অতিক্রম করলে পাঠায়। সতর্কতা ইমেল, Slack webhook, PagerDuty বা Cloud Functions (কাস্টম হ্যান্ডলিংয়ের জন্য) এর মাধ্যমে কনফিগার করা যেতে পারে। প্রতিটি সতর্কতায় রয়েছে: মেট্রিক নাম, বর্তমান মান, থ্রেশহোল্ড মান, অ্যাপ সংস্করণ, সেগমেন্ট (ডিভাইস, দেশ)। সতর্কতা ব্যবহারকারীদের নজরে আসার আগে পারফরম্যান্স অবনতিতে সাড়া দিতে দেয়।

প্রস্তাবিত থ্রেশহোল্ড শিল্প মান (Google I/O 2025) অনুসারে: কোল্ড স্টার্ট — 2 সেকেন্ডের কম, ওয়ার্ম স্টার্ট — 1 সেকেন্ডের কম, স্ক্রিন রেন্ডারিং — 500 ms-এর কম, HTTP রিকোয়েস্টের সময়কাল — 3000 ms-এর কম (95তম শতকরা), ধীর রিকোয়েস্টের অংশ — 5% এর কম। অত্যন্ত প্রতিযোগিতামূলক অ্যাপের জন্য (সোশ্যাল, ই-কমার্স), লক্ষ্য থ্রেশহোল্ড আরও কঠোর হতে পারে: কোল্ড স্টার্ট < 1.5 সেকেন্ড, HTTP < 1000 ms।

Firebase কনসোলে থ্রেশহোল্ড নির্ধারণ করা

Firebase কনসোলে, Performance বিভাগে যান, Thresholds ট্যাব খুলুন। প্রতিটি মেট্রিকের জন্য, পছন্দসই থ্রেশহোল্ড মান এবং ব্যবহারকারীদের শতাংশ নির্ধারণ করুন যা অতিক্রম দ্বারা প্রভাবিত হওয়া উচিত। উদাহরণ: "কোল্ড স্টার্টকে ধীর বিবেচনা করুন যদি এটি 10% এর বেশি ব্যবহারকারীর জন্য 2 সেকেন্ড অতিক্রম করে"। Firebase বাস্তবসম্মত থ্রেশহোল্ড চয়ন করতে সহায়তা করার জন্য বর্তমান মেট্রিক মান এবং অতিক্রমের ইতিহাস দেখাবে।

গুরুত্বপূর্ণ: থ্রেশহোল্ড ডেটা সংগ্রহকে প্রভাবিত করে না, তারা শুধু বিজ্ঞপ্তি তৈরি নিয়ন্ত্রণ করে। যদি থ্রেশহোল্ড খুব কম হয় (যেমন, কোল্ড স্টার্ট 1 সেকেন্ড, যদিও 50% ডিভাইস 3 সেকেন্ডে শুরু হয়), সতর্কতা ক্রমাগত আসবে এবং "গোলমাল" হয়ে যাবে যা ডেভেলপাররা লক্ষ্য করা বন্ধ করবে। বর্তমান পারফরম্যান্সের উপর ভিত্তি করে থ্রেশহোল্ড নির্ধারণ করুন, তারপর অ্যাপ অপ্টিমাইজ করার সাথে সাথে ধীরে ধীরে সেগুলি কঠোর করুন।

Firebase কনসোলে পারফরম্যান্স ড্যাশবোর্ড

পারফরম্যান্স ড্যাশবোর্ড মূল মেট্রিক্সকে সময় সিরিজ হিসাবে অ্যাপ সংস্করণ, ডিভাইস, দেশ, সংযোগের ধরন এবং OS সংস্করণ দ্বারা বিভক্ত করে প্রদর্শন করে। প্রতিটি মেট্রিকের জন্য নিম্নলিখিতগুলি উপলব্ধ: গড়, মধ্যমা, 95তম শতকরা, 99তম শতকরা। 95তম শতকরা হল পারফরম্যান্স মূল্যায়নের জন্য সবচেয়ে তথ্যপূর্ণ মেট্রিক, কারণ এটি দুর্বল ডিভাইসে অ্যাপ কিভাবে কাজ করে তা দেখায়, আউটলায়ার উপেক্ষা করে।

ড্যাশবোর্ড সংস্করণ তুলনা সমর্থন করে: মেট্রিক্সের ভিজুয়াল তুলনার জন্য দুটি অ্যাপ সংস্করণ (বর্তমান এবং পূর্ববর্তী) নির্বাচন করুন। যদি আপডেটের পর 95তম শতকরা স্টার্টআপ সময় 2.1 থেকে 3.4 সেকেন্ডে বেড়ে যায় — রিগ্রেশন স্পষ্ট, এবং আপনাকে সেই কমিট খুঁজে বের করতে হবে যা মন্দা সৃষ্টি করেছে। Firebase Performance GitHub, GitLab এবং Bitbucket-এর সাথে একীভূত হয়, যা নির্দিষ্ট কমিটের সাথে মেট্রিক পরিবর্তন লিঙ্ক করতে দেয়।

পারফরম্যান্স মনিটরিংয়ের জন্য কোড উদাহরণ

আসুন Kotlin ব্যবহার করে একটি Android অ্যাপে Firebase Performance Monitoring-এর একীকরণ উদাহরণ দেখি। কোডটি নিউজ ফিড লোডিং পরিমাপের জন্য একটি কাস্টম ট্রেস তৈরি, একটি স্বয়ংক্রিয়ভাবে না ধরা রিকোয়েস্টের জন্য HTTP বৈশিষ্ট্য যোগ এবং ইমেজ প্রসেসিং সময় পরিমাপের জন্য Trace ব্যবহার প্রদর্শন করে। সমস্ত উদাহরণ Remote Config-এর মাধ্যমে ট্রেসিং নিষ্ক্রিয় করার ক্ষমতা বিবেচনা করে।

ব্যবহারের আগে নির্ভরতা যোগ করুন: implementation("com.google.firebase:firebase-perf") Firebase BOM-এর মাধ্যমে। স্বয়ংক্রিয় ইন্সট্রুমেন্টেশনের জন্য, কোন অতিরিক্ত সেটআপ প্রয়োজন নেই — নির্ভরতা যোগ করার পর SDK স্বয়ংক্রিয়ভাবে মানক অপারেশন আটকায়।

ফিড লোডিংয়ের জন্য কাস্টম ট্রেস

প্রথম উদাহরণ — সার্ভার থেকে নিউজ ফিডের লোড সময় পরিমাপ। ট্রেস অ্যাসিঙ্ক্রোনাস fetchFeed অপারেশনকে মোড়ায়, যা নেটওয়ার্ক থেকে ডেটা আনে এবং JSON পার্স করে। ট্রেসে কাস্টম বৈশিষ্ট্য যোগ করা হয়েছে: ডেটা উৎস (cache বা network) এবং প্রাপ্ত পোস্টের সংখ্যা। এটি ডেটা বিভাজন করতে এবং বুঝতে দেয় যে কোন পরিস্থিতিতে ফিড সবচেয়ে ধীরে লোড হয়।

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

ফাংশন loadFeedWithTrace একটি source প্যারামিটার ("cache" বা "network") নেয়, যা ট্রেস বৈশিষ্ট্য হিসাবে ব্যবহৃত হয়। অ্যাসিঙ্ক্রোনাস অপারেশন শেষ হওয়ার পর, ট্রেস finally ব্লকে থামে, যা ব্যতিক্রমের ক্ষেত্রেও থামার নিশ্চয়তা দেয়। items_count মেট্রিক পোস্টের সংখ্যা লোড সময়কে কীভাবে প্রভাবিত করে তা বিশ্লেষণ করতে দেয়। Firebase কনসোলে, আপনি source বৈশিষ্ট্য দ্বারা ট্রেস ফিল্টার করতে পারেন এবং দেখতে পারেন যে নেটওয়ার্ক লোডিং ক্যাশের চেয়ে 3 গুণ ধীর।

অ-মানক রিকোয়েস্টের জন্য HTTP বৈশিষ্ট্য

দ্বিতীয় উদাহরণ — WebSocket-এর মাধ্যমে করা রিকোয়েস্টের জন্য HTTP বৈশিষ্ট্য (স্বয়ংক্রিয়ভাবে ধরা হয় না)। HttpMetric ক্লাস ব্যবহার করা হয়, যা ম্যানুয়ালি একটি URL রিকোয়েস্ট, এর পদ্ধতি, প্রতিক্রিয়া কোড এবং আকার নিবন্ধন করতে দেয়। Firebase এই রিকোয়েস্টটি স্বয়ংক্রিয়ভাবে ধরা রিকোয়েস্টের সাথে নেটওয়ার্ক রিকোয়েস্ট বিভাগে প্রদর্শন করবে।

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

উদাহরণে, sendWithHttpMetric একটি অ-মানক HTTP কল নিবন্ধনের জন্য newHttpMetric ব্যবহার করে। SDK এটি স্বয়ংক্রিয়ভাবে আটকায় না, তাই ডেভেলপার ম্যানুয়ালি URL, পদ্ধতি, প্রতিক্রিয়া কোড এবং আকার নির্ধারণ করে। কোয়েরি প্যারামিটার ছাড়া URL নির্ধারণ করা গুরুত্বপূর্ণ (নিরাপত্তা এবং একত্রিতকরণের জন্য) — অর্থাৎ /data, /data?token=abc নয়। Firebase স্বয়ংক্রিয়ভাবে অভিন্ন URL প্যাটার্ন গ্রুপ করে।

ইমেজ প্রসেসিং সময় পরিমাপ

তৃতীয় উদাহরণ কাস্টম ট্রেস ব্যবহার করে ইমেজ প্রসেসিং (কম্প্রেশন, আকার পরিবর্তন) এর সময় পরিমাপ প্রদর্শন করে। এই ক্ষেত্রে, ট্রেস একটি সিঙ্ক্রোনাস অপারেশন মোড়ায়, কিন্তু প্রোডাকশনের জন্য UI থ্রেড ব্লক করা এড়াতে coroutines বা RxJava ব্যবহার করুন।

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

ফাংশন compressImage 80% গুণমানে JPEG-তে ইমেজ কম্প্রেশন সময় পরিমাপ করে। format বৈশিষ্ট্য ভবিষ্যতে JPEG বনাম WebP কম্প্রেশন সময় তুলনা করতে দেয়। output_size_kb মেট্রিক দেখায় কম্প্রেশন কতটা কার্যকর। Firebase কনসোলে, আপনি বিতরণ দেখতে পারেন: দুর্বল ডিভাইসে (বাজেট Android), কম্প্রেশন ফ্ল্যাগশিপের তুলনায় 4 গুণ বেশি সময় নেয়, যা সার্ভারে ইমেজ আপলোড করার সময় বিলম্বের কারণ হতে পারে।

ডেটার ভিত্তিতে পারফরম্যান্স কীভাবে উন্নত করবেন

Firebase Performance ডেটা সরবরাহ করে কিন্তু প্রস্তুত সমাধান দেয় না। মেট্রিক্স বিশ্লেষণের জন্য প্রতিটি মেট্রিকের জন্য পারফরম্যান্স অবনতির সাধারণ কারণ বোঝা প্রয়োজন। আসুন প্রধান অবনতি প্যাটার্ন এবং Performance Monitoring ডেটা ব্যবহার করে সেগুলি নির্ণয়ের পদ্ধতি দেখি। পদ্ধতি: মেট্রিকে একটি অসঙ্গতি খুঁজুন → সাধারণ কারণ পরীক্ষা করুন → অপ্টিমাইজেশন প্রয়োগ করুন → এক সপ্তাহ পরে ফলাফল যাচাই করুন।

ধীর কোল্ড স্টার্ট (> 2 সেকেন্ড): কারণ — Application.onCreate-এ ভারী SDK ইনিশিয়ালাইজেশন (অ্যানালিটিক্স, ক্র্যাশ রিপোর্টিং, ম্যাপ SDK), বড় রিসোর্স লোড করা (ফন্ট, থিম), স্টার্টআপে মূল থ্রেডে সিঙ্ক্রোনাস অপারেশন। সমাধান: অলস SDK ইনিশিয়ালাইজেশন, বিলম্বিত রিসোর্স লোডিং, ইনিশিয়ালাইজেশনের সময় placeholder দেখানোর জন্য SplashScreen API (Android 12+) ব্যবহার। Firebase Performance দেখাবে কোন অ্যাপ সংস্করণ ধীর হতে শুরু করেছে — পরীক্ষা করুন কোন নির্ভরতা যোগ বা আপডেট করা হয়েছে।

ধীর স্ক্রিন রেন্ডারিং (> 500 ms): কারণ — জটিল View স্তরক্রম (নেস্টেড ConstraintLayout, একাধিক Fragment), UI থ্রেডে ডেটা লোড করা (নেটওয়ার্ক বা ডিস্ক), ভারী ড্র অপারেশন (বড় ইমেজ, কাস্টম View)। সমাধান: লেআউট স্তরক্রম অপ্টিমাইজ করুন (Android Studio-তে Layout Inspector), ব্যাকগ্রাউন্ড থ্রেডে ডেটা অফলোড করুন, Glide বা Coil-এর মাধ্যমে ইমেজ ক্যাশ করুন। সবচেয়ে ধীর স্ক্রিন খুঁজে প্রথমে অপ্টিমাইজ করতে Firebase-এ স্ক্রিন রেন্ডারিং ফিল্টার ব্যবহার করুন।

নেটওয়ার্ক রিকোয়েস্ট অপ্টিমাইজ করা

ধীর HTTP রিকোয়েস্ট (> 3 সেকেন্ড): কারণ — ধীর সার্ভার, বড় পেলোড, ক্যাশিংয়ের অভাব, উপ-অনুকূল প্রোটোকল (HTTP/2-এর পরিবর্তে HTTP/1.1), DNS রেজোলিউশন। সমাধান: সার্ভার সাইড পরীক্ষা করুন (আপটাইম, লেটেন্সি), প্রতিক্রিয়া আকার হ্রাস করুন (প্যাজিনেশন, GraphQL, JSON-এর পরিবর্তে protobuf), HTTP হেডার (Cache-Control) এর মাধ্যমে ক্যাশিং সক্ষম করুন, টাইমআউট এবং পুনরায় চেষ্টা লজিক যোগ করতে OkHttp Interceptor ব্যবহার করুন।

Firebase Performance রিকোয়েস্ট সময় বিতরণ দেখায়: DNS রেজোলিউশন, TCP হ্যান্ডশেক, TLS হ্যান্ডশেক, রিকোয়েস্ট পাঠানো, প্রতিক্রিয়া গ্রহণ। যদি বেশিরভাগ সময় DNS-এ ব্যয় হয় — DNS প্রিলোডিং (OkHttp DNS-over-HTTPS) ব্যবহার করুন। যদি TLS-এ — সেশন পুনরারম্ভ এবং সাইফার স্যুট টিউনিং ব্যবহার করুন। যদি প্রতিক্রিয়া গ্রহণে — প্রতিক্রিয়া আকার এবং ব্যবহারকারীর নেটওয়ার্ক গতি পরীক্ষা করুন। Firebase ডেটা প্রোটোকল স্তরে সমস্যা স্থানীয়করণ করতে দেয়, শুধু "রিকোয়েস্ট ধীর" বলার পরিবর্তে।

ট্রেসিং নিষ্ক্রিয় করার জন্য Remote Config একীকরণ

প্রোডাকশনের জন্য, একটি Remote Config ফ্ল্যাগ performance_tracing_enabled যোগ করার পরামর্শ দেওয়া হয়, যা দূরবর্তীভাবে কাস্টম ট্রেস নিষ্ক্রিয় করতে দেয়। যদি ক্লায়েন্টে Firebase Performance SDK খুব বেশি ডেটা তৈরি করে বা পারফরম্যান্স প্রভাবিত করে (দুর্বল ডিভাইসে), আপনি সমস্ত ব্যবহারকারীর জন্য ট্রেস নিষ্ক্রিয় করতে পারেন, শুধুমাত্র স্বয়ংক্রিয় মেট্রিক্স রেখে, যার ন্যূনতম ওভারহেড রয়েছে।

উদাহরণ লজিক: অ্যাপ স্টার্টআপে, Remote Config প্যারামিটার performance_tracing_enabled পরীক্ষা করুন। যদি false — Firebase.performance.newTrace()-এর সমস্ত কল একটি স্টাব অবজেক্ট ফেরত দেয় যা ডেটা সংগ্রহ করে না। এটি একটি র্যাপার ক্লাসের মাধ্যমে বাস্তবায়িত হয় যা ট্রেস তৈরি করার আগে ফ্ল্যাগ পরীক্ষা করে। এই পদ্ধতি সম্পূর্ণ শ্রোতাকে প্রভাবিত না করে নির্দিষ্ট ব্যবহারকারীদের (বিটা পরীক্ষক, ডেভেলপার) জন্য বিস্তারিত ট্রেসিং সক্ষম করতে দেয়।