পারফর্ম্যান্স মনিটরিং সংক্রান্ত সমস্যার সমাধান ও প্রায়শই জিজ্ঞাসিত প্রশ্ন

পারফর্ম্যান্স ইভেন্টের জন্য লগ মেসেজ কীভাবে দেখবেন

1. Performance Monitoring-এর জন্য বিল্ড করার সময় <meta-data> এলিমেন্ট যোগ করে আপনার অ্যাপের AndroidManifest.xml ফাইলে ডিবাগ লগিং চালু করুন, যেমন:

   <application>
       <meta-data
         android:name="firebase_performance_logcat_enabled"
         android:value="true" />
   </application>

2. কোনও সমস্যার মেসেজ আছে কিনা তা জানতে আপনার লগ মেসেজ চেক করুন।

3. Performance Monitoring FirebasePerformance দিয়ে এর লগ মেসেজ ট্যাগ করে। logcat ফিল্টারিং ব্যবহার করে, আপনি নিম্নলিখিত কমান্ড চালিয়ে নির্দিষ্টভাবে সময়সীমা ট্রেস ও HTTP/S নেটওয়ার্ক অনুরোধ লগিং দেখতে পারবেন:

   adb logcat -s FirebasePerformance

4. Performance Monitoring পারফর্ম্যান্স ইভেন্ট লগ করছে কিনা তা নির্ণয় করতে নিম্নলিখিত ধরনের লগ চেক করুন:

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. Firebase কনসোলে আপনার ডেটা দেখতে URL-এ ক্লিক করুন। ড্যাশবোর্ডে ডেটা আপডেট হতে কয়েক মুহূর্ত সময় লাগতে পারে।

আপনার অ্যাপ পারফর্ম্যান্স ইভেন্ট লগ না করলে, সমস্যার সমাধানকরণ সংক্রান্ত পরামর্শ পর্যালোচনা করুন।

অ্যাপে SDK যোগ করা হয়েছে, কিন্তু কনসোলে এখনও SDK যোগ করতে বলা হচ্ছে

আপনার অ্যাপ থেকে ইভেন্ট সংক্রান্ত তথ্য (যেমন, অ্যাপ ইন্টার‍্যাকশন) পেলে, Firebase বুঝতে পারে যে আপনি Performance Monitoring SDK আপনার অ্যাপে সফলভাবে যোগ করেছেন কিনা। সাধারণত, আপনার অ্যাপ চালু করার ১০ মিনিটের মধ্যে, Firebase কনসোলের পারফর্ম্যান্স ড্যাশবোর্ড একটি "SDK শনাক্ত করা হয়েছে" মেসেজ দেখায়। তারপর, ৩০ মিনিটের মধ্যে, ড্যাশবোর্ড প্রাথমিক প্রসেস করা ডেটা দেখায়।

আপনার অ্যাপে SDK-এর লেটেস্ট ভার্সন যোগ করার পর ১০ মিনিটের বেশি সময় হয়ে গেলেও আপনি এখনও কোনও পরিবর্তন দেখতে না পেলে, আপনার লগ মেসেজ চেক করে নিশ্চিত করুন যে Performance Monitoring ইভেন্ট লগ করছে। দেরিতে SDK শনাক্তকরণ মেসেজ সংক্রান্ত সমস্যার সমাধান করতে, নিচে বর্ণিত উপযুক্ত সমস্যা সমাধানকারী ধাপগুলি অনুসরণ করুন।

কনসোলে SDK শনাক্ত করা হয়েছে বলে দেখাচ্ছে, কিন্তু কোনও ডেটা দেখানো হচ্ছে না

Performance Monitoring পারফর্ম্যান্স ইভেন্ট ডেটা প্রসেস করার পরে তা পারফর্ম্যান্স ড্যাশবোর্ডে দেখায়।

"SDK শনাক্ত করা হয়েছে" মেসেজটি দেখানোর পর ২৪ ঘণ্টার বেশি সময় পেরিয়ে গিয়ে থাকলে, এবং আপনি এখনও ডেটা দেখতে না পেলে, কোনও পরিচিত আউটএজ আছে কিনা তা জানতে Firebase স্ট্যাটাস ড্যাশবোর্ড চেক করুন। কোনও আউটএজ না থাকলে, Firebase সহায়তায় যোগাযোগ করুন।

অ্যাপ পারফর্ম্যান্স ইভেন্ট লগ করছে না

আপনি পারফর্ম্যান্স ইভেন্টের জন্য লগ মেসেজ দেখতে না পেলে, সমস্যা সমাধানের জন্য নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

1. নিম্নলিখিত উপায়ে Performance Monitoring Gradle প্লাগ-ইনের সেট-আপ চেক করুন:

   1. আপনি সঠিক প্লাগ-ইন যোগ করেছেন কিনা তা ভালোভাবে দেখে নিন। বিশেষ করে, নিম্নলিখিত বিষয়গুলি চেক করুন:

      • আপনি প্লাগ-ইনটি (apply plugin: 'com.google.firebase.firebase-perf') আপনার মডিউল (অ্যাপ-লেভেল) build.gradle ফাইলে যোগ করেছেন।
      • আপনি প্লাগ-ইনের জন্য classpath নির্ভরতা যোগ করেছেন (classpath 'com.google.firebase:perf-plugin:2.0.2') আপনার প্রোজেক্ট-লেভেল build.gradle ফাইলে।

   2. নিশ্চিত করুন যে নিম্নলিখিত ফ্ল্যাগগুলির মাধ্যমে প্লাগ-ইন বন্ধ করা নেই:

      • instrumentationEnabled আপনার মডিউলে (অ্যাপ-লেভেল) build.gradle ফাইল
      • firebasePerformanceInstrumentationEnabled আপনার gradle.properties ফাইলে

2. আপনার AndroidManifest.xml ফাইলে নিম্নলিখিত ফ্ল্যাগগুলির মাধ্যমে Performance Monitoring SDK বন্ধ করা আছে কিনা তা চেক করুন:

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

3. Performance Monitoring যে বন্ধ করা নেই তা নিশ্চিত করুন রানটাইমে।

4. আপনার অ্যাপে কোনও কিছু বন্ধ করা আছে বলে খুঁজে না পেলে, Firebase সহায়তা টিমের সাথে যোগাযোগ করুন।

পারফর্ম্যান্স ড্যাশবোর্ডে স্ক্রিন ট্রেস ডেটা নেই

স্ক্রিন রেন্ডারিং ট্রেসের ডেটা দেখতে না পেলে, সমস্যার সমাধানকারী এইসব ধাপ অনুসরণ করুন:

1. আপনি Android SDK (v22.0.6)-এর লেটেস্ট ভার্সন ব্যবহার করছেন কিনা তা নিশ্চিত করুন। স্ক্রিন রেন্ডারিং ট্রেস শুধুমাত্র v15.2.0 বা তার পরবর্তী যেকোনও ভার্সনে উপলভ্য।

2. কোনও স্ক্রিনের জন্য আপনি ম্যানুয়ালি হার্ডওয়্যার অ্যাক্সিলারেশন বন্ধ করে দেননি তা নিশ্চিত করুন।

3. আপনি DexGuard বা Jack ব্যবহার করছেন না তা নিশ্চিত করুন। Performance Monitoring এই টুলচেনের সাথে মানানসই নয়।

   • DexGuard অ্যাপ চালু হওয়া, অ্যাপ-ইন-ফোরগ্রাউন্ড এবং অ্যাপ-ইন-ব্যাকগ্রাউন্ড ট্রেস অটোমেটিক সংগ্রহ করা বন্ধ করে দেয়। তবে, আপনার অ্যাপ DexGuard ব্যবহার করলে, যেকোনও কাস্টম কোড ট্রেস স্বাভাবিক আচরণ করবে।

   • Jack আর ব্যবহার করা হয় না এবং সাধারণত আপনার অ্যাপে ব্যবহার করা উচিত নয়।

পারফর্ম্যান্স ড্যাশবোর্ডে কাস্টম ট্রেস ডেটা নেই

আপনি কি অটোমেটিক সংগ্রহ করা ট্রেসের পারফর্ম্যান্স ডেটা দেখতে পাচ্ছেন কিন্তু কাস্টম কোড ট্রেসের জন্য নয়? সমস্যার সমাধান করতে নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

1. আপনি যদি Trace API-এর মাধ্যমে কাস্টম কোড ট্রেস ইনস্ট্রুমেন্ট করে থাকেন, তাহলে ট্রেসের সেট-আপ চেক করুন, বিশেষ করে নিম্নলিখিত বিষয়গুলি:

   • কাস্টম কোড ট্রেস ও কাস্টম মেট্রিকের নামকে নিম্নলিখিত প্রয়োজনীয়তা পূরণ করতে হবে: শুরুতে বা শেষে কোনও হোয়াইটস্পেস, শুরুতে কোনও আন্ডারস্কোর (_) অক্ষর এবং সর্বাধিক দৈর্ঘ্য ৩২ অক্ষর হতে পারবে না।
   • সব ট্রেস শুরু ও শেষ করতে হবে। কোনও ট্রেস শুরু না হলে, বন্ধ না হলে বা শুরু হওয়ার আগেই বন্ধ হয়ে গেলে, তা লগ করা হবে না।

2. আপনি যদি @AddTrace নোটেশন-এর মাধ্যমে কাস্টম কোড ট্রেস ইনস্ট্রুমেন্ট করে থাকেন, তাহলে Performance Monitoring Gradle প্লাগ-ইনের সেট-আপ চেক করুন:

   1. আপনি সঠিক প্লাগ-ইন যোগ করেছেন কিনা তা ভালোভাবে দেখে নিন। বিশেষ করে, নিম্নলিখিত বিষয়গুলি চেক করুন:

      • আপনি প্লাগ-ইনটি (apply plugin: 'com.google.firebase.firebase-perf') আপনার মডিউল (অ্যাপ-লেভেল) build.gradle ফাইলে যোগ করেছেন।
      • আপনি প্লাগ-ইনের জন্য classpath নির্ভরতা যোগ করেছেন (classpath 'com.google.firebase:perf-plugin:2.0.2') আপনার প্রোজেক্ট-লেভেল build.gradle ফাইলে।

   2. নিশ্চিত করুন যে নিম্নলিখিত ফ্ল্যাগগুলির মাধ্যমে প্লাগ-ইন বন্ধ করা নেই:

      • instrumentationEnabled আপনার মডিউলে (অ্যাপ-লেভেল) build.gradle ফাইল
      • firebasePerformanceInstrumentationEnabled আপনার gradle.properties ফাইলে

3. আপনার লগ মেসেজ চেক করুন যাতে Performance Monitoring প্রত্যাশিত কাস্টম কোড ট্রেস লগ করছে কিনা তা নিশ্চিত করা যায়।

4. Performance Monitoring ইভেন্ট লগ করলেও, ২৪ ঘণ্টা পরে কোনও ডেটা না দেখালে, Firebase সহায়তা টিমের সাথে যোগাযোগ করুন।

পারফর্ম্যান্স ড্যাশবোর্ডে নেটওয়ার্ক অনুরোধ সংক্রান্ত ডেটা নেই

নেটওয়ার্ক অনুরোধ সংক্রান্ত ডেটা দেখতে না পেলে, সমস্যার সমাধানের জন্য এইসব ধাপ অনুসরণ করুন:

1. Android অ্যাপের জন্য, Performance Monitoring Gradle প্লাগ-ইন এমন ইন্সট্রুমেন্টেশন চালু করে যা HTTP/S নেটওয়ার্ক অনুরোধের অটোমেটিক মনিটরিং প্রদান করে। নিম্নলিখিত বিষয়গুলি চেক করুন:

   1. আপনি সঠিক প্লাগ-ইন যোগ করেছেন কিনা তা ভালোভাবে দেখে নিন। বিশেষ করে, নিম্নলিখিত বিষয়গুলি চেক করুন:

      • আপনি প্লাগ-ইনটি (apply plugin: 'com.google.firebase.firebase-perf') আপনার মডিউল (অ্যাপ-লেভেল) build.gradle ফাইলে যোগ করেছেন।
      • আপনি প্লাগ-ইনের জন্য classpath নির্ভরতা যোগ করেছেন (classpath 'com.google.firebase:perf-plugin:2.0.2') আপনার প্রোজেক্ট-লেভেল build.gradle ফাইলে।

   2. নিশ্চিত করুন যে নিম্নলিখিত ফ্ল্যাগগুলির মাধ্যমে প্লাগ-ইন বন্ধ করা নেই:

      • instrumentationEnabled আপনার মডিউলে (অ্যাপ-লেভেল) build.gradle ফাইল
      • firebasePerformanceInstrumentationEnabled আপনার gradle.properties ফাইলে

2. নেটওয়ার্ক লাইব্রেরি ইনকম্প্যাটিবিলিটি চেক করুন। Performance Monitoring নিম্নলিখিত নেটওয়ার্কিং লাইব্রেরি ব্যবহার করে এমন নেটওয়ার্ক অনুরোধের জন্য মেট্রিক অটোমেটিক সংগ্রহ করে: OkHttp 3.x.x, Java-এর URLConnection এবং Apache HttpClient.

   মনে রাখবেন, আপনি নেটওয়ার্ক অনুরোধের জন্য কাস্টম মনিটরিং যোগ করতে পারবেন।

3. এগুলি সম্পর্কে সচেতন থাকুন:

   • আপনার কোডের আচরণ এবং আপনার কোডের ব্যবহার করা নেটওয়ার্কিং লাইব্রেরির উপর নির্ভর করে, Performance Monitoring শুধুমাত্র সম্পূর্ণ হওয়া নেটওয়ার্ক অনুরোধের ব্যাপারে রিপোর্ট করতে পারে। এর অর্থ হল, খোলা থাকা HTTP/S কানেকশন সম্পর্কে হয়ত রিপোর্ট করা হবে না।

   • DexGuard ও Jack-এর সাথে Performance Monitoring মানানসই নয়।

     • DexGuard HTTP/S নেটওয়ার্ক অনুরোধ মনিটর করা বন্ধ করে দেয়।
     • Jack আর ব্যবহার করা হয় না এবং সাধারণত আপনার অ্যাপে ব্যবহার করা উচিত নয়।

   • Performance Monitoring ভুল Content-Type হেডার সহ নেটওয়ার্ক অনুরোধের ব্যাপারে রিপোর্ট করে না। তবে, Content-Type হেডার ছাড়া নেটওয়ার্ক অনুরোধ এখনও গ্রহণ করা হবে।

নেটওয়ার্ক অনুরোধ সংক্রান্ত ডেটা প্রত্যাশা অনুযায়ী একত্রিত হচ্ছে না

URL প্যাটার্নের অধীনে Performance Monitoring কীভাবে নেটওয়ার্ক অনুরোধ ডেটা এগ্রিগেট করে সেই সম্পর্কে আরও জানুন।

এছাড়াও, আপনি কাস্টম URL প্যাটার্ন ব্যবহার করে দেখতে পারেন!

Project home-এ পারফর্ম্যান্স কার্ডে থাকা 'গুরুতর সমস্যা' বিকল্পের কী হল?

আমরা সর্বাধিক সমস্যা-এর পরিবর্তে সাম্প্রতিক সতর্কতা বিকল্প রেখেছি। এটি আমাদের সাম্প্রতিক সতর্কতা চালু করার ফলো-আপ হিসেবে করা হয়েছে। আপনার সেট করা থ্রেশহোল্ড অতিক্রম করা হলে, এটি আপনাকে অটোমেটিক বিজ্ঞপ্তি পাঠায়। সমস্যা এখন আর নেই এবং তার পরিবর্তে সতর্কতা দেখানো হয়।

পারফর্ম্যান্স কার্ডের উপরে অ্যাপ বেছে নেওয়ার বিকল্প সাম্প্রতিক সতর্কতা-এর অধীনে সতর্কতা এন্ট্রি ফিল্টার করে। বেছে নেওয়া অ্যাপের জন্য শুধুমাত্র তিনটি সবচেয়ে সাম্প্রতিক অ্যালার্ট দেখানো হয়।

সতর্কতা সম্পর্কে আরও জানতে, পারফর্ম্যান্স সংক্রান্ত সমস্যার জন্য সতর্কতা সেট-আপ করুন দেখুন।

কনসোলে সমস্যার জন্য থ্রেশহোল্ড সেট করার সুবিধাটি কী হল?

Performance Monitoring, আগে থেকে নির্ধারিত থ্রেশহোল্ড অতিক্রম করা মেট্রিকের জন্য অ্যালার্ট দেয়। পারফর্ম্যান্স মেট্রিকের জন্য কনফিগার করা যায় এমন থ্রেশহোল্ডের সাথে বিভ্রান্তি এড়াতে, আমরা সমস্যার জন্য থ্রেশহোল্ড কনফিগার করার সুবিধা সরিয়ে দিয়েছি।

Firebase কনসোলে বিবরণ ও মেট্রিক্স সংক্রান্ত তথ্যের কী হল?

সমস্যার সমাধান করার পদ্ধতি উন্নত করতে, আমরা বিবরণ ও মেট্রিক্স পৃষ্ঠার পরিবর্তে নতুন করে ডিজাইন করা, সেন্ট্রালাইজড ইউজার ইন্টারফেস (UI) যোগ করেছি। এই নতুন সমস্যার সমাধানকারী UI-তে বিবরণ ও মেট্রিক্সের মতো একই মূল ফাংশনালিটি রয়েছে। সমস্যার সমাধান সম্পর্কে আরও জানতে, নির্দিষ্ট ট্রেসের জন্য আরও ডেটা দেখুন।

নমুনার সংখ্যা আমার প্রত্যাশা অনুযায়ী কেন নয়?

Performance Monitoring আপনার অ্যাপের ব্যবহারকারীর ডিভাইস থেকে পারফর্ম্যান্স ডেটা সংগ্রহ করে। আপনার অ্যাপ্লিকেশনের অনেক ব্যবহারকারী থাকলে অথবা অ্যাপটি প্রচুর পরিমাণে পারফর্ম্যান্স অ্যাক্টিভিটি জেনারেট করলে, প্রসেস করা ইভেন্টের সংখ্যা কমাতে Performance Monitoring ডিভাইসের একটি সাবসেট থেকে ডেটা সংগ্রহ সীমিত করতে পারে। এইসব সীমা যথেষ্ট বেশি, যাতে, এমনকি কম ইভেন্ট থাকলেও, মেট্রিক ভ্যালু এখনও আপনার ব্যবহারকারীর অ্যাপ অভিজ্ঞতার প্রতিনিধিত্ব করে।

আমাদের সংগ্রহ করা ডেটার ভলিউম ম্যানেজ করতে, Performance Monitoring নিম্নলিখিত স্যাম্পেলিং বিকল্প ব্যবহার করে:

• ডিভাইসে রেট সীমিত করা: কোনও ডিভাইসকে হঠাৎ করে প্রচুর পরিমাণে ট্রেস পাঠানো থেকে আটকাতে, আমরা কোনও ডিভাইস থেকে পাঠানো কোড ও নেটওয়ার্ক রিকোয়েস্ট ট্রেসের সংখ্যা প্রতি ১০ মিনিটে ৩০০টি ইভেন্টে সীমিত করি। এই পদ্ধতিটি ডিভাইসকে লুপ করা ইনস্ট্রুমেন্টেশন থেকে রক্ষা করে যা প্রচুর পরিমাণে পারফর্ম্যান্স ডেটা পাঠাতে পারে এবং এটি পারফর্ম্যান্স পরিমাপকে স্কিউ করা থেকে একটি ডিভাইসকে বাধা দেয়।

• ডায়নামিক স্যাম্পেলিং: Performance Monitoring সব অ্যাপ ব্যবহারকারী জুড়ে প্রতিদিন অ্যাপ পিছু সীমিত সংখ্যক কোড ট্রেস এবং নেটওয়ার্ক অনুরোধ ট্রেস সংগ্রহ করে। কোনও র‍্যান্ডম ডিভাইসকে ট্রেস ক্যাপচার ও পাঠাতে হবে কিনা তা নির্ধারণ করতে ডিভাইস থেকে (Firebase Remote Config ব্যবহার করে) ডায়নামিক স্যাম্পলিং রেট সংগ্রহ করা হয়। স্যাম্পেলিংয়ের জন্য বেছে নেওয়া হয়নি এমন ডিভাইস কোনও ইভেন্ট পাঠায় না। ডায়নামিক স্যাম্পেলিং রেট হল অ্যাপ-নির্দিষ্ট এবং এটি অ্যাডজাস্ট করে নিশ্চিত করা হয় যে সংগ্রহ করা ডেটার সামগ্রিক ভলিউম সীমার মধ্যেই থাকে।

  যেসব প্রোজেক্টে BigQuery ইন্টিগ্রেশন চালু করা হয়েছে, সেগুলিতে নেটওয়ার্ক অনুরোধ ট্রেসের সংখ্যার জন্য আরও বেশি সীমা দেওয়া হয়।

  ব্যবহারকারীর সেশন, ব্যবহারকারীর ডিভাইস থেকে অতিরিক্ত, বিস্তারিত ডেটা পাঠায়, যার জন্য ডেটা ক্যাপচার ও পাঠানোর জন্য আরও রিসোর্স প্রয়োজন হয়। ব্যবহারকারীর সেশনের প্রভাব কমাতে, Performance Monitoring সেশনের সংখ্যাও সীমিত করতে পারে।

• সার্ভার-সাইড রেট লিমিটিং: অ্যাপ যাতে স্যাম্পেলিং সীমা অতিক্রম না করে তা নিশ্চিত করতে, Performance Monitoring ডিভাইস থেকে পাওয়া কিছু ইভেন্ট বাদ দেওয়ার জন্য সার্ভার-সাইড স্যাম্পেলিং ব্যবহার করতে পারে। এই ধরনের সীমাবদ্ধতা আমাদের মেট্রিকের কার্যকারিতা পরিবর্তন না করলেও, এটি সামান্য প্যাটার্ন শিফ্ট ঘটাতে পারে, যার মধ্যে নিম্নলিখিত বিষয়গুলি অন্তর্ভুক্ত:

  • কোনও কোড যতবার এক্সিকিউট করা হয়েছে, তার থেকে ট্রেসের সংখ্যা আলাদা হতে পারে।
  • কোডে ক্লোজলি কাপল করা ট্রেসগুলির প্রত্যেকটিতে আলাদা আলাদা সংখ্যক স্যাম্পেল থাকতে পারে।

কনসোলে সমস্যা ট্যাবের কী হল?

আমরা 'সমস্যা' ট্যাবের পরিবর্তে 'অ্যালার্ট' চালু করেছি, যা আপনার সেট করা থ্রেশহোল্ড অতিক্রম করলে আপনাকে অটোমেটিক বিজ্ঞপ্তি পাঠায়। থ্রেশহোল্ডের স্ট্যাটাস নির্ধারণ করতে আপনাকে আর ম্যানুয়ালি Firebase কনসোল চেক করতে হবে না। সতর্কতা সম্পর্কে জানতে, পারফর্ম্যান্স সংক্রান্ত সমস্যার জন্য সতর্কতা সেট-আপ করুন দেখুন।

কনসোলে ডিভাইসে ও নেটওয়ার্ক ট্যাবের কী হয়েছে? আমি কীভাবে সেইসব পৃষ্ঠায় থাকা ট্রেস দেখতে পাব?

আমরা Firebase কনসোলের Performance Monitoring বিভাগটি নতুন করে ডিজাইন করেছি যাতে ড্যাশবোর্ড ট্যাবে আপনার গুরুত্বপূর্ণ মেট্রিক ও সব ট্রেস একই জায়গায় দেখানো যায়। নতুন ডিজাইন করার অংশ হিসেবে, আমরা ডিভাইসে ও নেটওয়ার্ক পৃষ্ঠা সরিয়ে দিয়েছি।

ড্যাশবোর্ড ট্যাবের নিচে থাকা ট্রেস টেবিলে ডিভাইসে ও নেটওয়ার্ক ট্যাবে দেখানো একই তথ্য থাকে, তবে কিছু অতিরিক্ত ফিচার সহ। এর মধ্যে রয়েছে, নির্দিষ্ট মেট্রিকের জন্য শতাংশের পরিবর্তন অনুযায়ী আপনার ট্রেস সাজানোর ক্ষমতা। নির্দিষ্ট ট্রেসের সব মেট্রিক্স ও ডেটা দেখতে, ট্রেস টেবিলে ট্রেসের নামে ক্লিক করুন।

ট্রেস টেবিলের নিম্নলিখিত সাবট্যাবে আপনার ট্রেস দেখুন:

• নেটওয়ার্ক রিকোয়েস্ট ট্রেস (আউট-অফ-দ্য-বক্স ও কাস্টম, দুটিই) — নেটওয়ার্ক রিকোয়েস্ট সাবট্যাব
• কাস্টম কোড ট্রেস — কাস্টম ট্রেস সাবট্যাব
• অ্যাপ চালু করা, অ্যাপ-ইন-ফোরগ্রাউন্ড, অ্যাপ-ইন-ব্যাকগ্রাউন্ড ট্রেস — কাস্টম ট্রেস সাবট্যাব
• স্ক্রিন রেন্ডারিং ট্রেস — স্ক্রিন রেন্ডারিং সাবট্যাব
• পৃষ্ঠা লোড ট্রেস — পৃষ্ঠা লোড সাবট্যাব

ট্রেস টেবিল এবং মেট্রিক ও ডেটা দেখা সংক্রান্ত বিবরণের জন্য, কনসোলের ওভারভিউ পৃষ্ঠা (iOS+ | Android | ওয়েব) দেখুন।

ধীর গতির ও ফ্রিজ করা ফ্রেমের সংখ্যা আমার প্রত্যাশা অনুযায়ী কেন নয়?

ধীরে রেন্ডার হওয়া ফ্রেম ও ফ্রোজেন ফ্রেম, ডিভাইস রিফ্রেশ রেট ৬০Hz ধরে নিয়ে হিসেব করা হয়। কোনও ডিভাইসের রিফ্রেশ রেট ৬০Hz-এর কম হলে, প্রতিটি ফ্রেমের রেন্ডার করার সময় বেশি লাগবে কারণ প্রতি সেকেন্ডে কম ফ্রেম রেন্ডার করা হয়। রেন্ডার করার সময় বেশি লাগলে, আরও বেশি ধীর বা ফ্রিজ হয়ে যাওয়া ফ্রেমের ব্যাপারে অভিযোগ জানানো হতে পারে কারণ আরও বেশি ফ্রেম ধীরে ধীরে রেন্ডার করা হবে বা ফ্রিজ হয়ে যাবে। তবে, কোনও ডিভাইসের রিফ্রেশ রেট ৬০Hz-এর বেশি হলে, প্রতিটি ফ্রেমের রেন্ডার করার সময় কম লাগবে। এর ফলে কম সংখ্যক ধীর বা ফ্রিজ হওয়া ফ্রেম রিপোর্ট করা হতে পারে। Performance Monitoring SDK-তে এটি একটি বর্তমান সীমাবদ্ধতা।

আমি কেন ফ্র্যাগমেন্ট ট্রেস দেখতে পাচ্ছি না?

অ্যাপ অ্যাক্টিভিটি ছাড়াও ফ্র্যাগমেন্টের পারফর্ম্যান্স দেখতে, ভালোভাবে দেখে নিন যে আপনার অ্যাপ Performance Monitoring Android SDK 20.1.0 বা তার পরের যেকোনও ভার্সন ব্যবহার করছে কিনা। আরও জানতে, আপনার অ্যাপে পারফর্ম্যান্স মনিটরিং যোগ করুন দেখুন।

কোন ট্রেস ফ্র্যাগমেন্ট ও অ্যাক্টিভিটির সাথে সম্পর্কিত তা আমি কীভাবে বুঝব?

আপনার অ্যাপ্লিকেশনে যেভাবে সংজ্ঞায়িত করা হয়েছে সেই অনুযায়ী প্রতিটি ফ্র্যাগমেন্ট ও অ্যাক্টিভিটি ট্রেস তার ক্লাস নামের উপর ভিত্তি করে তৈরি হয়। স্ক্রিন ট্রেসের প্রতিটি অংশে st প্রিফিক্স থাকে তারপরে ক্লাসের নাম থাকে। Firebase কনসোলে, প্রিফিক্সটি সরিয়ে দেওয়া হয়। আরও জানতে, স্ক্রিন রেন্ডারিং পারফর্ম্যান্স ডেটা (Apple ও Android অ্যাপ) সম্পর্কে জানুন লিঙ্ক দেখুন।

আমি কেন অন্যান্য ট্রেসের তুলনায় কম ফ্র্যাগমেন্ট ট্রেস দেখতে পাচ্ছি?

Performance Monitoring কোনও ডিভাইসে সংগ্রহ করা সব ইভেন্ট জুড়ে ইভেন্ট স্যাম্পেলিং কন্ডাক্ট করে। এই পদ্ধতির মাধ্যমে, পারফর্ম্যান্স মেট্রিক্স প্রদান করার জন্য ব্যবহারকারীর ডিভাইস থেকে প্রয়োজনীয় ন্যূনতম ইভেন্ট সংগ্রহ করতে পারি।

আমার অ্যাপ্লিকেশনের রেন্ডারিং পারফর্ম্যান্স সংক্রান্ত কোনও সমস্যা হলে আমাকে কীভাবে জানানো হয়?

Performance Monitoring আপনাকে সেইসব মেট্রিকের জন্য অ্যালার্ট সেট-আপ করতে দেয় যেগুলি আপনার কাছে গুরুত্বপূর্ণ। জেনারেট করা স্ক্রিন রেন্ডারিং ট্রেসের জন্য, আপনি অ্যালার্ট সেট-আপ করতে পারবেন যাতে ধীর ও ফ্রিজ হওয়া ফ্রেমের শতাংশ আপনার সেট করা থ্রেশহোল্ড অতিক্রম করলে আপনাকে বিজ্ঞপ্তি পাঠানো হয়।

Performance Monitoring Gradle প্লাগ-ইন চালু করার পরে আমার বিল্ড টাইম অনেক বেশি। আমি কীভাবে এটি আরও ভাল করতে পারি?

Performance Monitoring Android-এর জন্য বাইটকোড ইনস্ট্রুমেন্টেশন ব্যবহার করে কিছু আউট-অফ-দ্য-বক্স ফিচার প্রদান করে, যেমন HTTP/S নেটওয়ার্ক অনুরোধ মনিটর করা। কম্পাইলেশনের অংশ হিসেবে, আপনার অ্যাপের (নির্ভরতা সহ) সমস্ত ক্লাস ইটারেট করার প্রসেস প্রয়োজন হয়, যাতে আপনার অ্যাপ্লিকেশনের নেটওয়ার্ক অনুরোধের পারফর্ম্যান্স মাপার জন্য গুরুত্বপূর্ণ কোড ইনস্ট্রুমেন্ট করা যায়।

বিল্ড টাইম বেড়ে যাওয়ার কিছু মূল কারণ এখানে দেওয়া হল:

• ক্লাস বা ফাইলের সংখ্যা
• সেইসব ক্লাসের প্রতিটি সাইজ (কোডের লাইন)
• আপনার মেশিনের কনফিগারেশন
• প্রাথমিক বিল্ড বনাম পরবর্তী বিল্ড (পরবর্তী বিল্ড সাধারণত প্রাথমিক বিল্ডের চেয়ে দ্রুত হয়)

বিল্ড টাইম অপ্টিমাইজ করতে, আপনার কোড মডিউলারাইজ করার কথা বিবেচনা করুন।

Performance Monitoring প্লাগ-ইনের v1.3.3 থেকে শুরু করে, আমরা ইনক্রিমেন্টাল বিল্ড প্রসেসিং এবং লাইব্রেরি ইনপুটের ক্যাশিংয়ে উল্লেখযোগ্য উন্নতি করার উপর মনোযোগ দিয়েছি। সবচেয়ে সাম্প্রতিক বিল্ড টাইম সংক্রান্ত উন্নতি পেতে, প্লাগ-ইনের লেটেস্ট ভার্সন (v2.0.2) ব্যবহার করছেন কিনা তা ভালোভাবে দেখে নিন।

মনে রাখবেন, আপনি যদি দীর্ঘক্ষণ ধরে বিল্ড করা এড়াতে চান, তাহলে আপনার স্থানীয়ভাবে ডিবাগ বিল্ডের জন্য প্লাগ-ইন বন্ধ করতে Performance Monitoring পারেন । তবে, প্রোডাকশন বিল্ডের জন্য এই পদ্ধতি সাজেস্ট করা হয় না, কারণ এর ফলে আপনার অ্যাপে নেটওয়ার্ক অনুরোধের জন্য পারফর্ম্যান্স পরিমাপ মিস হয়ে যেতে পারে।

Performance Monitoring Gradle প্লাগ-ইনের সাথে মানানসই নয় এমন লাইব্রেরির কারণে বিল্ড সংক্রান্ত সমস্যা হলে কী করব?

Performance Monitoring Android-এর জন্য বাইটকোড ইনস্ট্রুমেন্টেশন ব্যবহার করে কিছু আউট-অফ-দ্য-বক্স ফিচার প্রদান করে, যেমন HTTP/S নেটওয়ার্ক অনুরোধ মনিটর করা। কম্পাইলেশনের অংশ হিসেবে, আপনার অ্যাপের (নির্ভরতা সহ) সমস্ত ক্লাস ইটারেট করার প্রসেস প্রয়োজন হয়, যাতে আপনার অ্যাপ্লিকেশনের নেটওয়ার্ক অনুরোধের পারফর্ম্যান্স মাপার জন্য গুরুত্বপূর্ণ কোড ইনস্ট্রুমেন্ট করা যায়।

Performance Monitoring প্লাগ-ইনের সাথে ইন্টিগ্রেট করার পরে JSR/RET are not supported with computeFrames option বা এই ধরনের বিল্ড সংক্রান্ত সমস্যা হলে, এর কারণ হতে পারে যে আপনার কাছে এমন একটি লাইব্রেরির উপর নির্ভরতা রয়েছে যা Performance Monitoring Gradle প্লাগ-ইনের সাথে মানানসই নয়।

এটি এড়াতে, আপনি এইসব ধাপ অনুসরণ করে ইনস্ট্রুমেন্টেশন থেকে অনুপযুক্ত ক্লাস/লাইব্রেরি বাদ দিতে পারেন:

1. Performance Monitoring Gradle প্লাগ-ইনের (ন্যূনতম v1.4.0) লেটেস্ট ভার্সনে আপডেট করুন।
2. আপনার Android Gradle প্লাগ-ইন ভার্সন v7.2.0 বা তার পরবর্তী যেকোনও ভার্সনে আপডেট করুন।
3. ইনস্ট্রুমেন্টেশন থেকে অনুপযুক্ত ক্লাস/লাইব্রেরি বাদ দিতে, আপনার মডিউলে (অ্যাপ-লেভেল) build.gradle ফাইলে নিম্নলিখিত ফ্ল্যাগ যোগ করুন:

   android {
     // ...
     androidComponents {
       onVariants(selector().all(), {
           instrumentation.excludes.add("example.incompatible.library")
       })
     }
   }

   Android Gradle প্লাগ-ইনের Instrumentation API-এর exclude প্রপার্টি সম্পর্কে আরও জানতে, ইনস্ট্রুমেন্টেশন দেখুন।

ইনকম্প্যাটিবল লাইব্রেরির কারণে বিল্ড সংক্রান্ত সমস্যা হলে, Github-এ সমস্যা জমা দিন যাতে সেগুলি Performance Monitoring প্লাগ-ইন থেকে বাদ দেওয়া যায়।

আমার Performance Monitoring ডেটা BigQuery-তে এক্সপোর্ট করতে প্রত্যাশিত সময়ের চেয়ে বেশি সময় লাগছে। এটি কি রিয়েল-টাইম নয়?

আপনি Firebase Performance Monitoring-এর জন্য BigQuery ইন্টিগ্রেশন চালু করে থাকলে, আপনার ডেটা দিন শেষ হওয়ার ১২ থেকে ২৪ ঘণ্টা পরে BigQuery-তে এক্সপোর্ট করা হবে (প্যাসিফিক টাইম)।

যেমন, ১৯ এপ্রিলের ডেটা ২০ এপ্রিল দুপুর ১২টা থেকে মধ্যরাতের মধ্যে BigQuery-তে উপলভ্য হবে (সব তারিখ ও সময় প্যাসিফিক টাইম অনুযায়ী)।

আমি কতগুলি কাস্টম URL প্যাটার্ন তৈরি করতে পারি?

আপনি প্রতিটি অ্যাপের জন্য মোট ৪০০টি পর্যন্ত কাস্টম URL প্যাটার্ন এবং সেই অ্যাপের প্রতিটি ডোমেনের জন্য ১০০টি পর্যন্ত কাস্টম URL প্যাটার্ন তৈরি করতে পারবেন।

"প্রায় রিয়েল-টাইম" পারফর্ম্যান্স ডেটা বলতে কী বোঝায়?

Firebase Performance Monitoring প্রসেস, পারফর্ম্যান্স ডেটা আসার সাথে সাথেই তা সংগ্রহ করে, যার ফলে Firebase কনসোলে প্রায় রিয়েল-টাইম ডেটা ডিসপ্লে করা হয়। সংগ্রহ করার কয়েক মিনিটের মধ্যেই কনসোলে প্রসেস করা ডেটা দেখানো হয়, তাই "প্রায় রিয়েল-টাইম" কথাটি ব্যবহার করা হয়েছে।

প্রায় রিয়েল-টাইম ডেটা প্রসেসিংয়ের সুবিধা পেতে, আপনার অ্যাপ যেন রিয়েল-টাইম মানানসই SDK ভার্সন ব্যবহার করে তা নিশ্চিত করুন।

আমার অ্যাপের জন্য কীভাবে প্রায় রিয়েল-টাইম পারফর্ম্যান্স ডেটা পাব?

প্রায় রিয়েল-টাইম ডেটা প্রসেসিংয়ের সুবিধা নিতে, আপনাকে শুধু এটি নিশ্চিত করতে হবে যে আপনার অ্যাপ এমন Performance Monitoring SDK ভার্সন ব্যবহার করে যা রিয়েল-টাইম ডেটা প্রসেসিংয়ের সাথে মানানসই।

এগুলি হল রিয়েল-টাইম কম্প্যাটিবল SDK ভার্সন:

• iOS — v7.3.0 বা তার পরবর্তী যেকোনও ভার্সন
• tvOS — v8.9.0 বা তার পরবর্তী যেকোনও ভার্সন
• Android — v19.0.10 বা এর পরের যেকোনও ভার্সন (অথবা Firebase Android BoM v26.1.0 বা এর পরের যেকোনও ভার্সন)
• ওয়েব — v7.14.0 বা তার পরবর্তী যেকোনও ভার্সন

মনে রাখবেন, আমরা সবসময় SDK-এর লেটেস্ট ভার্সন ব্যবহার করার সাজেশন দিই, তবে উপরে তালিকাভুক্ত যেকোনও ভার্সন Performance Monitoring আপনার ডেটা প্রায় রিয়েল টাইমে প্রসেস করতে পারবে।

Performance Monitoring SDK-এর কোন ভার্সন রিয়েল-টাইম কম্প্যাটিবল হিসেবে বিবেচিত হয়?

এইসব SDK ভার্সন রিয়েল-টাইম ডেটা প্রসেসিংয়ের সাথে মানানসই:

• iOS — v7.3.0 বা তার পরবর্তী যেকোনও ভার্সন
• tvOS — v8.9.0 বা তার পরবর্তী যেকোনও ভার্সন
• Android — v19.0.10 বা এর পরের যেকোনও ভার্সন (অথবা Firebase Android BoM v26.1.0 বা এর পরের যেকোনও ভার্সন)
• ওয়েব — v7.14.0 বা তার পরবর্তী যেকোনও ভার্সন

মনে রাখবেন, আমরা সবসময় SDK-এর লেটেস্ট ভার্সন ব্যবহার করার সাজেশন দিই, তবে উপরে তালিকাভুক্ত যেকোনও ভার্সন Performance Monitoring আপনার ডেটা প্রায় রিয়েল টাইমে প্রসেস করতে পারবে।

রিয়েল-টাইম মানানসই SDK ভার্সন ব্যবহার করার জন্য আমি অ্যাপ আপডেট না করলে কী হবে?

আপনার অ্যাপ রিয়েল-টাইম মানানসই SDK ভার্সন ব্যবহার না করলেও, আপনি এখনও Firebase কনসোলে আপনার অ্যাপের সব পারফর্ম্যান্স ডেটা দেখতে পাবেন। তবে, পারফর্ম্যান্স ডেটা সংগ্রহ করার সময় থেকে সেটি দেখাতে মোটামুটি ৩৬ ঘণ্টা দেরি হবে।

আমি রিয়েল-টাইম কম্প্যাটিবল SDK ভার্সনে আপডেট করেছি, কিন্তু আমার কিছু ব্যবহারকারী এখনও আমার অ্যাপের পুরনো ভার্সন ব্যবহার করছেন। আমি কি Firebase কনসোলে তাদের পারফর্ম্যান্স ডেটা দেখতে পাব?

হ্যাঁ! অ্যাপ ইনস্ট্যান্স যে SDK ভার্সনই ব্যবহার করুক না কেন, আপনি সব ব্যবহারকারীর পারফর্ম্যান্স ডেটা দেখতে পাবেন।

তবে, আপনি যদি সাম্প্রতিক ডেটা (মোটামুটি ৩৬ ঘণ্টার কম পুরনো) দেখেন, তাহলে ডিসপ্লে করা ডেটা হল রিয়েল-টাইম মানানসই SDK ভার্সন ব্যবহার করা অ্যাপ ইনস্ট্যান্সের ব্যবহারকারীদের থেকে পাওয়া। তবে, সাম্প্রতিক নয় ডেটার মধ্যে আপনার অ্যাপের সব ভার্সন থেকে পাওয়া পারফর্ম্যান্স ডেটা অন্তর্ভুক্ত থাকে।

আমি কেন পারফর্ম্যান্স ডেটার রিয়েল-টাইম ডিসপ্লে দেখতে পাচ্ছি না?

রিয়েল-টাইম পারফর্ম্যান্স ডেটা দেখতে, আপনার অ্যাপ এমন Performance Monitoring SDK ভার্সন ব্যবহার করছে কিনা তা নিশ্চিত করুন যা রিয়েল-টাইম ডেটা প্রসেসিংয়ের সাথে মানানসই।

• iOS — v7.3.0 বা তার পরবর্তী যেকোনও ভার্সন
• tvOS — v8.9.0 বা তার পরবর্তী যেকোনও ভার্সন
• Android — v19.0.10 বা এর পরের যেকোনও ভার্সন (অথবা Firebase Android BoM v26.1.0 বা এর পরের যেকোনও ভার্সন)
• ওয়েব — v7.14.0 বা তার পরবর্তী যেকোনও ভার্সন

মনে রাখবেন, আমরা সবসময় SDK-এর লেটেস্ট ভার্সন ব্যবহার করার সাজেশন দিই, তবে উপরে তালিকাভুক্ত যেকোনও ভার্সন Performance Monitoring আপনার ডেটা প্রায় রিয়েল টাইমে প্রসেস করতে পারবে।