ব্রেন্ডান গ্রেগের ল্যাটেন্সি এবং প্রোফাইলিং জন্য পারফরম্যান্স পদ্ধতি

কেন ব্রেন্ডান গ্রেগের দৃষ্টিভঙ্গি অনুমান কমায়

ব্রেন্ডান গ্রেগ সিস্টেম পারফরম্যান্সে—বিশেষ করে লিনাক্স জগতেই—একজন অত্যন্ত প্রভাবশালী কণ্ঠ। তিনি বহুল ব্যবহৃত বই লিখেছেন, ব্যবহারিক টুল তৈরি করেছেন এবং—সবচেয়ে জরুরি—বাস্তব প্রোডাকশন সমস্যাগুলো অনুসন্ধানের পরিষ্কার পদ্ধতি শেয়ার করেছেন। টিমগুলো তার পদ্ধতি গ্রহণ করে কারণ এটি চাপের মধ্যে কাজ করে: যখন ল্যাটেন্সি বাড়ে এবং সবাই উত্তর চায়, তখন আপনাকে "হয়তো এটা X" থেকে "এটা নিশ্চিতভাবে Y"-তে ন্যূনতম নাটক নিয়ে চলে যেতে হবে।

“পারফরম্যান্স পদ্ধতি” আসলে কী বোঝায়

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

এই পুনরাবৃত্ততা অনুমান কমায়। সবচেয়ে বেশি অনুভবক্ষম বা সবচেয়ে জোরে বলা ব্যক্তির উপর নির্ভর করার পরিবর্তে, আপনি একটি সঙ্গতিপূর্ণ প্রক্রিয়া অনুসরণ করেন যা:

• সমস্যাকে নির্দিষ্ট একটি রিসোর্স, সার্ভিস, বা কোড পাথে সংকুচিত করে
• ঘটনার সাথে একই টাইম উইন্ডোতে যা ঘটছে তা মাপায়
• পরিবর্তন করার আগে প্রমাণসহ বটলনেক নিশ্চিত করে

সাধারণ ব্যর্থতার মোড: পরিমাপের আগে ঠিক করা

অনেক ল্যাটেন্সি তদন্ত প্রথম পাঁচ মিনিটেই ভুল হয়ে যায়। মানুষ সরাসরি সমাধানে ঝাঁপিয়ে পড়ে: “CPU বাড়ান,” “সার্ভিস রিস্টার্ট করুন,” “ক্যাশ বাড়ান,” “GC টিউন করুন,” “অবশ্যই নেটওয়ার্ক।” কখনও কখনও এসব সহায়ক হয়—কিন্তু প্রায়ই তারা সিগনাল লুকিয়ে দেয়, সময় নষ্ট করে বা নতুন ঝুঁকি তৈরি করে।

গ্রেগের পদ্ধতিগুলো আপনাকে “সমাধান” বিলম্বিত করতে বাধ্য করে যতক্ষণ না আপনি সহজ প্রশ্নগুলোর উত্তর দিতে পারেন: কী স্যাচুরেটেড? কী ত্রুটি দিচ্ছে? কী ধীরে হয়েছে—থ্রুপুট, কিউইং, না ব্যক্তিগত অপারেশন?

এই গাইডটি কী সহায়তা করবে

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

লাটেন্সির ভিত্তি: টিউন করার আগে কী মাপবেন

লেটেন্সি একটি লক্ষণ: ব্যবহারকারীরা কাজ শেষ হওয়ার জন্য অপেক্ষা করে বেশি সময় নেন। কারণ সাধারণত অন্য কোথাও থাকে—CPU প্রতিযোগিতা, ডিস্ক বা নেটওয়ার্ক ওয়েট, লক কনটেনশন, গারবেজ কালেকশন, কিউইং, বা রিমোট ডিপেন্ডেন্সি ডিলে। কেবল ল্যাটেন্সি মাপা বলে ব্যথা আছে, তা বলে না কোথা থেকে শুরু হচ্ছে।

থ্রুপুট, ল্যাটেন্সি, এবং ত্রুটি একসাথে বদলে যায়

এই তিনটি সিগনাল সংযুক্ত:

• থ্রুপুট (রিকোয়েস্ট/সেকেন্ড) বাড়লে কিউইং বাড়তে পারে, যা ল্যাটেন্সি বাড়ায়।
• ত্রুটি দেখা দেয়া ল্যাটেন্সি কমিয়ে দিতে পারে (ফাস্ট ফেইল), অথবা বাড়িয়ে দিতে পারে (রিট্রাই ও টাইমআউট)।
• থ্রুপুট সীমিত করা (রেট লিমিট, ব্যাকপ্রেজার) টেইল ল্যাটেন্সি উন্নত করতে পারে কিন্তু সফল রিকোয়েস্ট কমানোও হতে পারে।

টিউন করার আগে একই টাইম উইন্ডোর জন্য এই তিনটি ধরে রাখুন। অন্যথায় আপনি কাজ বাদ দিয়ে বা দ্রুত ব্যর্থ করে ল্যাটেন্সি “ফিক্স” করতে পারেন।

গড়মানের ওপর নির্ভর করবেন না: পার্সেন্টাইল ও টেইল ল্যাটেন্সি

গড় ল্যাটেন্সি স্পাইকগুলো লুকায় যা ব্যবহারকারীরা মনে রাখে। ৫০ মি.সে. গড় থাকা সত্ত্বেও সার্ভিসে বারবার ২ সেকেন্ড স্টল থাকতে পারে।

পার্সেন্টাইল ট্র্যাক করুন:

• p50: সাধারণ ব্যবহারকারীর অভিজ্ঞতা
• p95/p99: টেইল ল্যাটেন্সি (এখানেই বেশিরভাগ সমস্যা থাকে)

ল্যাটেন্সির আকৃতিও দেখুন: p50 স্থিতিশীল কিন্তু p99 বাড়লে তা অন্তরায়যুক্ত স্টল (যেমন লক কনটেনশন, I/O হিকআপ, স্টপ-দ্য-ওয়ার্ল্ড পজ) নির্দেশ করে, সাধারণ ধীরগতির নয়।

ল্যাটেন্সি বাজেট: সময় কোথায় ব্যয় করা যায়

ল্যাটেন্সি বাজেট একটি সহজ হিসাব: “যদি রিকোয়েস্ট 300 ms-এ শেষ করতে হয়, সময় কোথায় ব্যয় করা যাবে?” এটিকে ভাঙুন:

• আপনার সার্ভিসে সময় (কম্পিউট + অপেক্ষা)
• ডাউনস্ট্রীম সার্ভিসে সময়
• ডেটাবেস/ক্যাশে সময়
• নেটওয়ার্ক ট্রানজিট ও TLS
• কিউতে থাকা সময় (থ্রেড, কনেকশন পুল, লোড ব্যালান্সার)

এই বাজেট প্রথম পরিমাপ কাজটিকে ফ্রেম করে: স্পাইকের সময় কোন বালতি (bucket) বেড়েছে তা চিহ্নিত করুন, তারপর সেই অংশটাই তদন্ত করুন, অন্ধভাবে টিউন না করে।

পরিষ্কার প্রশ্ন ও স্কোপ দিয়ে শুরু করুন

যখন কোনো সমস্যা বর্ণনা করা হয় "সিস্টেম ধীর"—তখন ল্যাটেন্সি কাজ ভেঙে যায়। গ্রেগের পদ্ধতি আগেই শুরু করে: সমস্যাকে একটি নির্দিষ্ট, পরীক্ষাযোগ্য প্রশ্নে প্ররোচিত করে।

“ধীরে” মানে কী (আর কার জন্য) নির্ধারণ করুন

কোনো টুল স্পর্শ করার আগে দুইটি বাক্য লিখুন:

• কি ধীরে? (পেজ লোড, API এন্ডপয়েন্ট, ব্যাচ জব, লগইন, চেকআউট, একটি নির্দিষ্ট SQL কুয়েরি)
• কোথায় ধীরে দেখা যাচ্ছে? (কাস্টমার ব্রাউজার, মোবাইল অ্যাপ, একটি রিজিওন, একটি পড, একটি হোস্ট, একটি ইনটার্নাল সার্ভিস)

এটি আপনাকে ভুল লেয়ার অপ্টিমাইজ করা থেকে রোধ করে—যেমন যদি ব্যথা একটি নির্দিষ্ট এন্ডপয়েন্ট বা ডাউনস্ট্রীম ডিপেনডেন্সি-তে সীমাবদ্ধ থাকে তবুও হোস্ট CPU-কে টিউন করলে ভুল হবে।

একটি টাইম উইন্ডো এবং স্কোপ নির্বাচন করুন

অভিযোগের সাথে মানায় এমন একটি উইন্ডো নিন এবং সম্ভব হলে একটি “ভালো” তুলনা সময়ও রাখুন।

স্পষ্টভাবে স্কোপ করুন:

• হোস্ট vs সার্ভিস vs এন্ডপয়েন্ট: “একটি Kubernetes নোড” আলাদা “একটি API রুট” থেকে।
• ট্রাফিকের কোন স্লাইস: রিজিওন, কাস্টমার টিয়ার, শুধু ত্রুটিপূর্ণ রিকোয়েস্ট, বা সব রিকোয়েস্ট।
• কোন সিগনাল রিপোর্ট চালাচ্ছে: p95 ল্যাটেন্সি, টাইমআউট, কিউ গভীরতা, বা ইউজার টাইমিং।

এখানে সঠিক হতে হলে পরবর্তী ধাপগুলি (USE, RED, প্রোফাইলিং) দ্রুত হবে কারণ আপনি জানবেন কোন ডেটা পরিবর্তিত হওয়া উচিত যদি আপনার হাইপোথিসিস সঠিক হয়।

সাম্প্রতিক পরিবর্তনগুলোকে হাইপোথিসিস হিসেবে দেখুন, উত্তর হিসেবে নয়

ডিপ্লয়, কনফিগ চেঞ্জ, ট্রাফিক শিফট, ইনফ্রা ইভেন্টগুলো লিপিবদ্ধ করুন—কিন্তু কারণটি ধরে নেবেন না। এগুলোকে লিখুন “যদি X হয়, তবে আমরা Y প্রত্যাশা করব,” যাতে আপনি দ্রুত নিশ্চিত বা বাতিল করতে পারেন।

হালকা তদন্ত লগ রাখুন

একটি ছোট লগ সহকর্মীদের মধ্যে পুনরাবৃত্ত কাজ প্রতিরোধ করে এবং হ্যান্ডঅফ সহজ করে।

Time | Question | Scope | Data checked | Result | Next step

এমন পাঁচটি লাইনও একটি চাপগ্রস্ত ঘটনা পুনরাবৃত্ত প্রক্রিয়ায় রূপান্তর করতে পারে।

USE পদ্ধতি: রিসোর্স বটলনেক দ্রুত ইনভেন্টরি

USE পদ্ধতি (Utilization, Saturation, Errors) গ্রেগের দ্রুত চেকলিস্ট—CPU, মেমরি, ডিস্ক (স্টোরেজ), এবং নেটওয়ার্ক—স্ক্যান করে যাতে আপনি অনুমান বন্ধ করে সংকোচন শুরু করতে পারেন।

এটি কী: প্রতিটি রিসোর্সের জন্য চেকলিস্ট

ডজন টাকার ড্যাশবোর্ডের দিকে তাকানোর বদলে, প্রতিটি রিসোর্স জন্য একই তিনটি প্রশ্ন করুন:

• Utilization: এটি এখন কত ব্যস্ত?
• Saturation: কাজ জমে আছে কি (কিউ, অপেক্ষার সময়), যদিও utilization সর্বোচ্চ নাও হতে পারে?
• Errors: এটি কীভাবে ব্যর্থ হচ্ছে বা রিট্রাই করছে যা বিলম্ব সৃষ্টি করছে?

নিয়মিত প্রয়োগ করলে এটি দ্রুতই বোঝায় কোথায় চাপ আছে।

ব্যবহারিক প্রয়োগ

CPU-র ক্ষেত্রে, utilization হল CPU ব্যস্ততার %, saturation দেখায় রান-কিউ চাপ বা থ্রেডগুলো চলার জন্য অপেক্ষা করছে, এবং errors-এ থাকতে পারে কন্টেইনার থ্রোটলিং বা খারাপ ইন্টারাপ্ট যে আচরণ করছে।

মেমরি-তে utilization হল ব্যবহৃত মেমরি, saturation হিসেবে পেইজিং বা ঘন ঘন গারবেজ কালেকশন দেখা যায়, এবং errors-এ অ্যালোকেশন ফেইল বা OOM ইভেন্ট অন্তর্ভুক্ত।

ডিস্ক-ে utilization হল ডিভাইস ব্যস্ত সময়, saturation হল কিউ গভীরতা ও রিড/রাইট ওয়েট টাইম, এবং errors-এ I/O ত্রুটি বা টাইমআউট থাকে।

নেটওয়ার্ক-এ utilization হল থ্রুপুট, saturation হল ড্রপ/কিউ/ল্যাটেন্সি, এবং errors-এ রিট্রান্সমিট, রিসেট বা প্যাকেট লস থাকে।

ল্যাটেন্সি ঘটনার সময় সবচেয়ে দরকারী সিগন্যাল

ইউজাররা ধীরে অনুভব করলে স্যাচুরেশন সিগন্যাল প্রায়ই সবচেয়ে বেশি প্রকাশ্যে আসে: কিউ, অপেক্ষার সময়, ও কনটেনশন সাধারণত ল্যাটেন্সির সাথে সরাসরি সম্পর্কিত।

USE সার্ভিস মেট্রিক্সের সংযুক্তি (স্থান গ্রহণ করে না)

সার্ভিস-লেভেল মেট্রিক্স (রিকোয়েস্ট ল্যাটেন্সি ও ত্রুটি হার মত) আপনাকে ইমপ্যাক্ট বলে। USE বলে কোথায় দেখতে হবে—কোন রিসোর্সে চাপ আছে।

একটি ব্যবহারিক লুপ:

1. ইউজার ইমপ্যাক্ট নিশ্চিত করুন (Duration/Errors)
2. USE ইনভেন্টরি চালান
3. সন্দেহজনক রিসোর্সে গভীর টুলিং (প্রোফাইল, ট্রেস, কেল-স্ট্যাট) দিয়ে ঝুমা দিন

RED পদ্ধতি: ব্যবহারকারী-প্রথম সিগন্যাল যা ইমপ্যাক্ট নির্দেশ করে

RED পদ্ধতি আপনাকে হোস্ট গ্রাফে ডুব দেওয়ার আগে ব্যবহারকারীর অভিজ্ঞতার ওপর ধরে রাখে।

• Rate: আপনার সার্ভিস বা এন্ডপয়েন্ট কত রিকোয়েস্ট/সেকেন্ড করছে
• Errors: কত রিকোয়েস্ট ব্যর্থ হচ্ছে (এবং আপনার অ্যাপের জন্য “ব্যর্থতা” কী বোঝায়)
• Duration: সফল রিকোয়েস্টগুলো কতক্ষণ নিচ্ছে (পার্সেন্টাইল হিসেবে ট্র্যাক করুন, গড় নয়)

কেন RED আপনাকে অগ্রাধিকার দিতে সাহায্য করে

RED আপনাকে “ইন্টারেস্টিং” সিস্টেম মেট্রিক অনুসরণ করা থেকে রোধ করে যা ব্যবহারকারীদের প্রভাবিত করে না। এটি একটি সঙ্কীর্ণ লুপ আরোপ করে: কোন এন্ডপয়েন্ট ধীর, কোন ব্যবহারকারীদের জন্য, এবং কবে থেকে? যদি Duration কেবল এক রুটে স্পাইক করে আর মোট CPU ফ্ল্যাট থাকে, আপনি ইতিমধ্যেই একটি তীক্ষ্ণ সূচনা পেয়েছেন।

একটি উপকারী অভ্যাস: RED সার্ভিস ও শীর্ষ এন্ডপয়েন্ট দ্বারা ভাঙুন (বা প্রধান RPC মেথড)। এতে একটি বিস্তৃত অবনতি ও লোকালাইজড রিগ্রেশন আলাদা করা সহজ হয়।

RED লক্ষণকে USE চেকের সাথে মানচিত্র করুন

RED আপনাকে কোথায় ব্যথা হচ্ছে বলে। USE আপনাকে পরীক্ষা করতে সাহায্য করে কোন রিসোর্স দায়ী।

উদাহরণ:

• Duration বাড়ল + Rate স্থিতিশীল → স্যাচুরেশন/কিউইং পরীক্ষা করুন: CPU রান কিউ, স্টোরেজ ল্যাটেন্সি, DB কানেকশন পুল।
• Errors বাড়ল + Duration বাড়ল → টাইমআউট ও রিট্রাই পরীক্ষা করুন: ওভারলোডেড ডাউনস্ট্রিম, থ্রেড পুল, নেটওয়ার্ক ড্রপ।
• Rate বাড়ল + Duration বাড়ল → ক্যাপাসিটি সীমা পরীক্ষা করুন: CPU utilization, লোড ব্যালান্সার আচরণ, অটোস্কেলিং বিলম্ব।

একটি মিনিমাল “কি বদলেছে?” ড্যাশবোর্ড

লেআউটকে ফোকাসযুক্ত রাখুন:

1. RED ওভারভিউ: সার্ভিসের Rate, Errors, এবং p50/p95/p99 Duration
2. শীর্ষ এন্ডপয়েন্ট: একই RED সিগন্যাল এন্ডপয়েন্টভিত্তিক, ট্র্যাফিক বা খারাপ p95 অনুযায়ী সাজানো
3. ডিপেনডেন্সি: প্রধান ডাউনস্ট্রিম (DB, ক্যাশ, এক্সটার্নাল API) জন্য RED-স্টাইল প্যানেল
4. একটি করিলেশন সারি: কয়েকটি সিস্টেম মেট্রিক (CPU, মেমরি প্রেসার, ডিস্ক I/O ল্যাটেন্সি, নেটওয়ার্ক রিট্রান্সমিট) যাতে সার্ভিস ভিউ থেকে রুট-কারণ পরীক্ষায় দ্রুত ঝাঁপ দেওয়া যায়

একটি ধারাবাহিক ইনসিডেন্ট ওয়ার্কফ্লো চাইলে এই অংশটিকে USE ইনভেন্টরির সাথে জোড়া দিন (/blog/use-method-overview) যাতে আপনি "ইউজাররা অনুভব করছে" থেকে "এই রিসোর্সই কনস্ট্রেন্ট"-এ কম থ্র্যাশ দিয়ে যেতে পারেন।

অগ্রাধিকরণ: পরবর্তী সবচেয়ে ভালো প্রশ্নটি বেছে নিন

একটি পারফরম্যান্স তদন্ত কয়েক মিনিটে ডজনগুলো চার্ট ও হাইপোথিসিসে বিস্তৃত হতে পারে। গ্রেগের মানসিকতা হল এটিকে সংকীর্ণ রাখা: আপনার কাজ "আরো ডেটা সংগ্রহ করা" নয়, বরং পরের সেই প্রশ্ন জিজ্ঞেস করা যা সবচেয়ে দ্রুত অনিশ্চয়তা দূর করবে।

বটলনেকের জন্য 80/20 নিয়ম

অধিকাংশ ল্যাটেন্সি সমস্যাই একক খরচ (বা অল্প কিছু) দ্বারা আধিপত্য করে: একটি হট লক, একটি ধীর ডিপেন্ডেন্সি, একটি ওভারলোডেড ডিস্ক, একটি GC প্যাটার্ন। অগ্রাধিকরণ মানে প্রথমে সেই ডোমিন্যান্ট খরচ খোঁজা, কারণ পাঁচটি জায়গায় 5% করে কমানো সাধারণত ব্যবহারকারীর দৃশ্যমান ল্যাটেন্সি সরাবে না।

একটি ব্যবহারিক পরীক্ষা: “আমাদের দেখা ল্যাটেন্সি পরিবর্তনের বেশিরভাগ কে ব্যাখ্যা করতে পারবে কী?” যদি একটি হাইপোথিসিস কেবল একটি ছোট অংশ ব্যাখ্যা করে, তা নিম্ন-অগ্রাধিকার।

টপ-ডাউন বনাম বটম-আপ: কোথায় শুরু করবেন

টপ-ডাউন ব্যবহার করুন যখন আপনি উত্তর দিচ্ছেন “ব্যবহারকারীরা ক্ষতিগ্রস্ত কিনা?” এন্ডপয়েন্ট থেকে শুরু করুন (RED-স্টাইল): ল্যাটেন্সি, থ্রুপুট, ত্রুটি। এই পদ্ধতি আপনাকে এমন কিছু অপ্টিমাইজ করা থেকে রোধ করে যা কৃতিক্যাল পাথে নেই।

বটম-আপ ব্যবহার করুন যখন হোস্ট স্পষ্টভাবে খারাপ অবস্থা (USE-স্টাইল লক্ষণ): CPU স্যাচুরেশন, রানঅ্যাওয়ে মেমরি প্রেসার, I/O ওয়েট। যদি একটি নোড পেগড থাকে, আপনি এন্ডপয়েন্ট পার্সেন্টাইল দেখে সময় নষ্ট করবেন কারণ_constraint বোঝা যাবে না।

থ্র্যাশ রোধের জন্য একটি সহজ সিদ্ধান্ত গাছ

যখন এলার্ট আসে, একটি শাখা বেছে নিন এবং সেটাতেই থাকুন যতক্ষণ না আপনি নিশ্চিত বা বাতিল করেন:

• ল্যাটেন্সি স্পাইক + ত্রুটি স্পাইক → “এটা ডিপেন্ডেন্সি নাকি ক্যাপাসিটি ইভেন্ট?” (টাইমআউট, কনেকশন পুল এক্সহসট, ডাউনস্ট্রিম 5xx)
• ল্যাটেন্সি স্পাইক + CPU স্পাইক → “CPU কি কার্যকর কাজ করছে নাকি আটকে আছে?” (on-CPU বনাম off-CPU সময়)
• ল্যাটেন্সি স্পাইক + উচ্চ I/O ওয়েট → “কোন ডিভাইস বা ফাইলসিস্টেম কিউ ব্যাক করছে?”
• রিসপন্স স্পাইক রিসোর্স স্পাইক ছাড়া → “সময় কোথায় অপেক্ষা করছে?” (লক, শিডিউলার, নেটওয়ার্ক, রিমোট কল)

মেট্রিক ওভারলোড থেকে দূরে থাকুন, পদ্ধতিগত থাকুন

আপনি নিজেকে ছোট একটি সিগন্যাল সেট পর্যন্ত সীমাবদ্ধ রাখুন, তারপর কেবল যখন কিছু চলে তখনই ড্রিল ডাউন করুন। যদি আপনাকে একটি চেকলিস্ট দরকার, আপনার ধাপগুলো একটি রানবুকের সাথে লিঙ্ক করুন (/blog/performance-incident-workflow) যাতে প্রতিটি নতুন মেট্রিকের একটি উদ্দেশ্য থাকে: একটি নির্দিষ্ট প্রশ্নের উত্তর দেওয়া।

প্রোডাকশনে প্রোফাইলিং—সিস্টেম ডাউন না করে

প্রোডাকশনে প্রোফাইলিং ঝুঁকিপূর্ণ মনে হতে পারে কারণ এটি লাইভ সিস্টেম স্পর্শ করে—তবুও এটি প্রায়শই বিতর্ককে প্রমাণে সেরা পথ। লগ ও ড্যাশবোর্ড বলে থাকে কী ধীর হচ্ছে; প্রোফাইলিং বলে কোথায় সময় যাচ্ছে: কোন ফাংশন হট, কোন থ্রেড অপেক্ষায়, কোন কোড পাথ ডমিনেট করছে।

প্রোফাইলিং আসলে কী উত্তর দেয়

প্রোফাইলিং একটি "সময় বাজেট" টুল। তত্ত্ববাদের বদলে ("এটা DB" বনাম "এটা GC"), আপনি প্রমাণ পান: "CPU স্যাম্পলগুলোর 45% JSON পারসিং-এ ছিল" বা "অধিকাংশ রিকোয়েস্ট একটি মিউটেক্সে ব্লক ছিল।" এটি পরবর্তী ধাপকে এক বা দুই কংক্রিট ফিক্সে সংকীর্ণ করে।

প্রোডাকশনে ব্যবহারযোগ্য সাধারণ ধরনগুলো

• CPU প্রোফাইলিং: কোন কোড অন-CPU চালিত হচ্ছে তা দেখায়।
• Off-CPU (wait) প্রোফাইলিং: থ্রেডগুলো কীভাবে ব্লক হচ্ছে (I/O ওয়েট, শিডিউলার ডিলে, স্লিপ, নেটওয়ার্ক, ডিস্ক) তা দেখায়।
• লক প্রোফাইলিং: কনটেনশন দেখায়—লক/মিউটেক্স/রিড-রাইট ল্যাচে অপেক্ষার সময়।

প্রতিটিটি একটি আলাদা প্রশ্নের উত্তর দেয়। ল্যাটেন্সি বেশি কিন্তু CPU কম থাকলে সাধারণত off-CPU বা লক টাইম নির্দেশ করে অন-CPU হটস্পট নয়।

অলওয়েজ-অন বনাম অন-ডিম্যান্ড

• অলওয়েজ-অন প্রোফাইলিং (কন্টিনিউয়াস, কম ওভারহেড) “পুষে পাখা” রহস্যের জন্য সাহায্য করে কারণ আপনি পেছনে ফিরে দেখতে পারবেন।
• অন-ডিম্যান্ড প্রোফাইলিং লক্ষ্যভিত্তিক ক্যাপচার যা স্পাইকের সময় ধরার সহজ পদ্ধতি। এটি নেওয়া সহজ, তবে আপনাকে দ্রুত ট্রিগার দিতে প্রস্তুত থাকতে হবে।

অনেক দল অন-ডিম্যান্ড দিয়ে শুরু করে, তারপর নিরাপত্তা বিশ্বাস করা ও পুনরাবৃত্ত সমস্যা দেখা দিলে অলওয়েজ-অন-এ গ্র্যাজুয়েট করে।

নিরাপত্তা: ওভারহেড, স্যাম্পলিং, এবং ছোট উইন্ডোজ

প্রোডাকশন-সেইফ প্রোফাইলিং ওয়েট কন্ট্রোল করা। সর্বদা স্যাম্পলিং পছন্দ করুন (প্রতিটি ইভেন্ট ট্রেস না করে), ক্যাপচার উইন্ডো ছোট রাখুন (উদাহরণস্বরূপ 10–30 সেকেন্ড), এবং ক্যানারি-তে আগে ওভারহেড মাপুন। সন্দেহ হলে, কম-ফ্রিকোয়েন্সি স্যাম্পলিং দিয়ে শুরু করুন এবং সিগন্যাল যদি শব্দজনিত হয় তবেই বাড়ান।

ফ্লেম গ্রাফ: কীভাবে পড়বেন এবং ভুল সিদ্ধান্ত এড়াবেন

ফ্লেম গ্রাফগুলি প্রোফাইলিং উইন্ডোর সময় কোন স্থানে স্যাম্পল সময় কেটে গেছে তা ভিজ্যুয়ালাইজ করে। প্রতিটি "বক্স" একটি ফাংশন (বা স্ট্যাক ফ্রেম), এবং প্রতিটি স্ট্যাক দেখায় কিভাবে সম্পাদন ওই ফাংশনে পৌঁছেছে। এগুলো দ্রুত প্যাটার্ন ধরতে চমৎকার—কিন্তু তারা অটোম্যাটিকভাবে বলে না “বাগ এখানেই।”

ফ্লেম গ্রাফ কী দেখায় (আর কী দেখায় না)

ফ্লেম গ্রাফ সাধারণত on-CPU স্যাম্পল প্রতিনিধিত্ব করে: প্রোগ্রাম যখন সত্যিই CPU কোরে চালছিল তখন সময়। এটি CPU-ভিত্তিক কোডপাথ, অপ্রয়োজনীয় পার্সিং, অতিরিক্ত সিরিয়ালাইজেশন বা সূক্ষ্ম হটস্পট হাইলাইট করতে পারে।

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

প্রস্থ এবং স্ট্যাক গভীরতা পড়া

• প্রস্থ: ওই ফ্রেমটি স্যাম্পলে কতবার দেখা গিয়েছে। বিস্তৃত মানে সাধারণত “অধিক CPU সময়,” কিন্তু শুধুমাত্র নির্বাচিত টাইম উইন্ডোর মধ্যে।
• স্ট্যাক গভীরতা: কল ডেপথ। গভীর স্ট্যাক নিজে থেকে খারাপ নয়; গুরুত্বপূর্ণ হলো কোন পাথ ডমিনেট করছে এবং তা কি আপনার কাজের সাথে মেলে।

সাধারণ ফাঁদ থেকে সাবধান

বিস্তৃত বক্সকে দোষারোপ করা কৌতূহল তৈরি করে, কিন্তু প্রশ্ন করুন: এটি কি আপনি বদলাতে পারবেন এমন একটি হটস্পট, না upstream-এর কারণে malloc, GC, বা লগিং-এ সময় কাটছে? এছাড়াও JIT, ইনলাইনিং, সিম্বল অনুপস্থিতি প্রেক্ষাপটে কনটেক্সট মিসিং থাকতে পারে, ফলে একটি বক্স অপরাধী হিসেবে উঠে আসে যখন তা কেবল ম্যাসেঞ্জার।

নির্দিষ্ট প্রশ্নের সাথে ফ্লেম গ্রাফ জোড়া

ফ্লেম গ্রাফকে একটি সীমাবদ্ধ প্রশ্নের উত্তর হিসেবে বিবেচনা করুন: কোন এন্ডপয়েন্ট, কোন টাইম উইন্ডো, কোন হোস্ট, এবং কি বদলেছে। "বিফোর বনাম আফটার" (বা "হেলদি বনাম ডিগ্রেডেড") ফ্লেম গ্রাফ তুলনা করুন একই রিকোয়েস্ট পাথে যাতে প্রোফাইলিং শব্দ এড়ানো যায়।

Off-CPU সময়: ল্যাটেন্সির লুকানো উৎস

ল্যাটেন্সি স্পাইক হলে অনেক টিম প্রথমে CPU% দেখে। এটা বোধগম্য—তবুও প্রায়ই ভুল দিকে নির্দেশ করে। একটি সার্ভিস মাত্র 20% CPU-তে থেকেও আর্তনাদজনকভাবে ধীর হতে পারে যদি থ্রেডগুলো তাদের বেশিরভাগ সময় চলমান না করে কাটায়।

কেন কেবল CPU% বিভ্রান্ত করে

CPU% প্রশ্নের উত্তর দেয় "প্রসেসর কত ব্যস্ত?" এটি উত্তর দেয় না "আমার রিকোয়েস্ট সময় কোথায় গেল?" রিকোয়েস্ট থ্রেড ঘুমাচ্ছে, ব্লক করা, বা পার্কড থাকলে ওয়াল-ক্লক সময় আবারও বাড়ে।

একটি মূল ধারণা: একটি রিকোয়েস্টের ওয়াল-ক্লক সময়ে আছে on-CPU কাজ এবং off-CPU অপেক্ষা উভয়ই।

সাধারণ off-CPU অপরাধীরা

Off-CPU সময় সাধারণত ডিপেন্ডেন্সি ও কনটেনশনের পিছনে লুকানো থাকে:

• ডিস্ক I/O: সিনক্রোনাস রিড/রাইট, fsync, ধীর স্টোরেজ, পেইজ ক্যাশ মিস
• নেটওয়ার্ক ওয়েট: DNS লুকআপ, TCP রিট্রান্সমিট, ওভারলোডেড আপস্ট্রীম সার্ভিস
• লক ও মিউটেক্স কনটেনশন: থ্রেডগুলো লকের জন্য ব্লক
• কিউইং: থ্রেড পুল, কনেকশন পুল, বা অভ্যন্তরীণ ওয়ার্ক কিউতে অপেক্ষা

লক্ষণগুলো দেখার মত

কিছু সিগনাল প্রায়ই off-CPU বটলনেকের সাথে সম্পর্কিত:

• বাড়ছে কিউ টাইম (রিকোয়েস্ট শুরু হওয়ার আগে অপেক্ষা)
• রানএবল থ্রেড বাড়ছে (CPU সময় পেতে আরো প্রতিযোগিতা)
• বেড়ে উঠা I/O ওয়েট ও দীর্ঘ ডিস্ক/নেটওয়ার্ক ল্যাটেন্সি

এই লক্ষণগুলো বলে “আমরা অপেক্ষা করছি,” কিন্তু কী জন্য অপেক্ষা করছি তা বলে না।

Off-CPU প্রোফাইলিং কীভাবে “কোথায় সময় গেল” দেখায়

Off-CPU প্রোফাইলিং সময়কে সেই কারণে অ্যাট্রিবিউট করে যার জন্য আপনি চলছে না: সিস্টেম কলেই ব্লক, লকের ওপর অপেক্ষা, স্লিপ, বা ডিসকাশেড হওয়া। এটি ল্যাটেন্সি কাজের জন্য শক্তিশালী কারণ এটি অস্পষ্ট ধীরগতি কার্যকর বিভাগে রূপান্তর করে: “মিউটেক্স X-এ ব্লক,” “disk থেকে read()-এ অপেক্ষা,” বা “upstream-এ connect()-এ আটকে।” একবার আপনি অপেক্ষার নাম বলতে পারেন, আপনি এটি মাপতে, নিশ্চিত করতে এবং ঠিক করতে পারবেন।

অনুমান নয় প্রমাণ দিয়ে বটলনেক নিশ্চিত করুন

পারফরম্যান্স কাজ প্রায়ই একই মুহূর্তে ফেইল করে: কেউ একটি সন্দেহজনক মেট্রিক দেখে সেটাকে “সমস্যা” বলে ঘোষণা করে এবং টিউন শুরু করে। গ্রেগের পদ্ধতি আপনাকে ধীর হতে এবং সীমা নির্ধারণ করা পর্যন্ত প্রমাণ করতে বাধ্য করে।

বটলনেক, হটস্পট, এবং নয়েজ

একটি বটলনেক হল সেই রিসোর্স/কম্পোনেন্ট যা বর্তমানে থ্রুপুটকে ক্যাপ কিংবা ল্যাটেন্সি চালায়। যদি আপনি এটিকে লাঘব করেন, ব্যবহারকারীরা উন্নতি দেখবে।

একটি হটস্পট হল যেখানে সময় কাটে (উদাহরণস্বরূপ, প্রোফাইলে একটি ফাংশন ঘনঘন দেখা যায়)। হটস্পট বটলনেক হতে পারে—বা কেবল ব্যস্ত কাজ যা স্লো পাথকে প্রভাবিত করে না।

নয়েজ হল এমন সবকিছু যা অর্থপূর্ণ দেখায় কিন্তু তা নয়: ব্যাকগ্রাউন্ড জব, এককালীন স্পাইক, স্যাম্পলিং আর্টিফ্যাক্ট, ক্যাশিং প্রভাব, বা "টপ টকার" যা ব্যবহারকারীর দৃশ্যমান সমস্যার সাথে সম্পর্কহীন।

তুলনা ও নিয়ন্ত্রিত পরিবর্তন দিয়ে প্রমাণ করুন

শুরু করুন একটি পরিষ্কার before স্ন্যাপশট ক্যাপচার করে: ইউজার-ফেসিং সিম্পটম (ল্যাটেন্সি বা ত্রুটি হার) এবং প্রধান সন্দেহজনক সিগন্যাল (CPU স্যাচুরেশন, কিউ গভীরতা, ডিস্ক I/O, লক কনটেনশন ইত্যাদি)। তারপর একটি নিয়ন্ত্রিত পরিবর্তন করুন যা কেবল আপনার সন্দেহভাজন কারণটাকেই প্রভাবিত করা উচিত।

কার্যকারিতা পরীক্ষা:

• সন্দেহভাজন রিসোর্সে ক্যাপাসিটি বাড়ান (একটি আরও ওয়ার্কার, বেশি CPU শেয়ার, বড় কনেকশন পুল) এবং দেখুন ল্যাটেন্সি উন্নত হয় কি না।
• সাময়িকভাবে ডিমান্ড কমান (একটি noisy এন্ডপয়েন্টকে সীমাবদ্ধ করুন, ছোট ওয়ার্লোড রেপ্লে করুন) এবং দেখুন সন্দেহভাজন কনস্ট্রেইন্ট ঢিলে পড়ে কি না।

করিলেশন একটি ইঙ্গিত; একে ফাইনাল রায় ভাববেন না। যদি “CPU বাড়লে ল্যাটেন্সি বাড়ে” দেখেন, CPU উপলব্ধতা পরিবর্তন বা CPU কাজ কমিয়ে যাচাই করুন যে ল্যাটেন্সি অনুসরণ করে কি না।

আপনি যা প্রমাণ করেছেন তা ডকুমেন্ট করুন

লিখে রাখুন: কী মাপা হয়েছিল, ঠিক কোন পরিবর্তন করা হয়েছিল, before/after ফলাফল, ও দেখা উন্নতি। এটি এককালীন জয়ের বদলে একটি পুনর্ব্যবহারযোগ্য প্লেবুক তৈরি করে এবং ভবিষ্যতে “ইন্টুইশন” ইতিহাস বদলে দেয়া থেকে রোধ করে।

পারফরম্যান্স ইনসিডেন্টের জন্য পুনরাবৃত্ত ওয়ার্কফ্লো তৈরি করুন

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

ইনসিডেন্ট লুপ: সনাক্ত → ট্রায়াজ → পরিমাপ → ফিক্স

সনাক্ত: ইউজার-ফেসিং ল্যাটেন্সি ও ত্রুটি হারে এলার্ট দিন, কেবল CPU নয়। যখন p95/p99 ল্যাটেন্সি একটি স্থায়ী উইন্ডো পার করে তখন পেজিং করুন।

ট্রায়াজ: দ্রুত তিনটি প্রশ্নের উত্তর দিন: কি ধীরে, কখন শুরু, এবং কারা প্রভাবিত? যদি আপনি স্কোপ (সার্ভিস, এন্ডপয়েন্ট, রিজিওন, কোহর্ট) বলতে না পারেন, আপনি অপ্টিমাইজ করার জন্য প্রস্তুত নন।

পরিমাপ: এমন প্রমাণ সংগ্রহ করুন যা বটলনেক সংকীর্ণ করে। সময়সীমাবদ্ধ ক্যাপচার (উদাহরণ: 60–180 সেকেন্ড) পছন্দ করুন যাতে আপনি “খারাপ” বনাম “ভালো” তুলনা করতে পারেন।

ফিক্স: একবারে এক জিনিস বদলান, তারপর একই সিগন্যালগুলো পুনরায় মাপুন উন্নতি নিশ্চিত করতে এবং প্ল্যাসিবো বাদ দিতে।

ছোট গ্রাফ সেট স্ট্যান্ডার্ডাইজ করুন

একটি শেয়ারড ড্যাশবোর্ড রাখুন যাতে সবাই ইনসিডেন্টে ব্যবহার করে। এটিকে বোরিং ও কনসিস্টেন্ট রাখুন:

• ল্যাটেন্সি: p50 / p95 / p99 (প্রতিরিক্ত এন্ডপয়েন্ট অনুযায়ী)
• RED সিগন্যাল: Rate, Errors, Duration (সার্ভিস-ফার্স্ট ভিউ)
• কিছু USE মেট্রিক: CPU, ডিস্ক, নেটওয়ার্কের utilization, saturation, errors

লক্ষ্য সবকিছু গ্রাফ করা নয়; এটি প্রথম-তথ্য-উদ্ধারির সময় ছোট করা।

প্রতিটি কৃতিক্যাল এন্ডপয়েন্টের জন্য “গোল্ডেন সিগন্যাল” নির্ধারণ করুন

যে এন্ডপয়েন্টগুলো সবচেয়ে গুরুত্বপূর্ণ (চেকআউট, লগইন, সার্চ) সেগুলোতে ইনস্ট্রুমেন্ট করুন, সব এন্ডপয়েন্ট নয়। প্রত্যেকটির জন্য সম্মত হোন: প্রত্যাশিত p95, সর্বোচ্চ ত্রুটি হার, এবং মূল ডিপেনডেন্সি (DB, ক্যাশ, থার্ড-পার্টি)।

ইনসিডেন্টে কী ক্যাপচার করবেন তা ঠিক করুন

পরবর্তী আউটেজের আগে, একটি ক্যাপচার কিটে সম্মত হোন:

• প্রোফাইল (CPU ও off-CPU), প্লাস ফ্লেম গ্রাফ
• ধীর এন্ডপয়েন্টের ট্রেস
• ত্রুটি/টাইমআউটের জন্য লোগ (স্যাম্পল করা)

এটি /runbooks/latency-তে সংক্ষিপ্ত রানবুক হিসেবে ডকুমেন্ট করুন, কে ক্যাপচার চালাতে পারে এবং আর্টিফ্যাক্ট কোথায় সংরক্ষণ হবে তা উল্লেখ করে।

Koder.ai কোথায় ফিট করে একটি গ্রেগ-স্টাইল ওয়ার্কফ্লোতে

গ্রেগের মেথডোলজি মুলত নিয়ন্ত্রিত পরিবর্তন ও দ্রুত যাচাই-র ওপর ভিত্তি করে। যদি আপনার টিম Koder.ai (একটি চ্যাট-ড্রিভেন প্ল্যাটফর্ম ওয়েব, ব্যাকএন্ড, ও মোবাইল অ্যাপ তৈরি ও ইটারেট করার জন্য) ব্যবহার করে সার্ভিস তৈরি করে, দুইটি ফিচার এই মানসিকতার সাথে সাদৃশ্যপূর্ণ:

• Planning Mode আপনাকে “হয়তো এটা X”―কে একটি স্পষ্ট হাইপোথিসিস ও একটি ছোট, টেস্টেবল পরিবর্তন সেটে রূপান্তর করতে সাহায্য করে প্রোডাকশনে ছোঁবার আগে।
• Snapshots and rollback নিরাপদ, এক-ভেরিয়েবল এক্সপেরিমেন্ট সমর্থন করে: একটা পরিবর্তন করুন, RED/USE সিগন্যাল মাপুন, এবং প্রমাণ বললে দ্রুত রোলব্যাক করুন।

আপনি যদি ইনসিডেন্টে নতুন কোড তৈরি না করলেও, ছোট ডিফ, পরিমাপযোগ্য ফলাফল, ও দ্রুত উল্টানোর অভ্যাসগুলোই গ্রেগ প্রচার করে।

একটি ব্যবহারিক ওয়াকথ্রু: ল্যাটেন্সি স্পাইক থেকে যাচাই করা ফিক্স পর্যন্ত

পরিস্থিতি: পিক ট্রাফিকে p99 লাফ

10:15am—আপনার ড্যাশবোর্ড দেখাচ্ছে API-এর p99 ল্যাটেন্সি ~120ms থেকে ~900ms-এ লাফিয়েছে পিক ট্রাফিকে। ত্রুটি হার স্থিতিশীল, কিন্তু কাস্টমাররা ধীর রিকোয়েস্ট রিপোর্ট করছে।

ধাপ 1 — ইউজার ইমপ্যাক্ট জানতে RED দিয়ে শুরু করুন

সার্ভিস-ফার্স্ট: Rate, Errors, Duration।

আপনি Duration এন্ডপয়েন্ট অনুযায়ী স্লাইস করলে দেখতে পাবেন একটি রুট p99-এ ডমিনেট করছে: POST /checkout। Rate 2× বাড়েছে, ত্রুটি স্বাভাবিক, কিন্তু কনকারেন্সি বাড়লে Duration স্পাইক করে—এটা কিউইং বা কনটেনশন ইঙ্গিত করে, সরাসরি ফেইল নয়।

পরবর্তী ধাপে পরীক্ষা করুন latency compute টাইম নাকি waiting time: অ্যাপ্লিকেশন “হ্যান্ডলার টাইম” বনাম মোট রিকোয়েস্ট টাইম তুলনা করুন (ট্রেসিং থাকলে upstream/span)। হ্যান্ডলার টাইম কম, মোট টাইম বেশি—রিকয়েস্টগুলো অপেক্ষায় আছে।

ধাপ 2 — সন্দেহভাজন হোস্ট(গুলি) এ USE প্রয়োগ করুন

ইনভেন্টরি করে দেখুন: Utilization, Saturation, Errors—CPU, মেমরি, ডিস্ক, নেটওয়ার্ক।

CPU utilization মাত্র ~35%, কিন্তু CPU run queue ও কনটেক্সট স্যুইচ বাড়ছে। ডিস্ক ও নেটওয়ার্ক steady। ওই মিল (কম CPU% কিন্তু বেশি অপেক্ষা) একটি ক্লাসিক সংকেত: থ্রেডগুলো CPU বার্ণ করছে না—তারা ব্লক হচ্ছে।

ধাপ 3 — লক্ষণ অনুযায়ী প্রোফাইলিং বেছে নিন

• যদি CPU উচ্চ: CPU প্রোফাইলিং (on-CPU ফ্লেম গ্রাফ) ব্যবহার করুন।
• যদি রিকোয়েস্ট অপেক্ষায় থাকে: off-CPU প্রোফাইলিং দেখুন থ্রেডগুলো কীসে ব্লক করছে (লক, I/O, শিডিউলার)।

আপনি স্পাইকের সময় একটি off-CPU প্রোফাইল ক্যাপচার করলে একটি শেয়ার করা “promotion validation” ক্যাশের চারপাশে মিউটেক্সে প্রচুর সময় ব্লক করা দেখা যায়।

ধাপ 4 — ফিক্স, তারপর যাচাই

আপনি গ্লোবাল লক বদলে পার-কী লক (বা লক-ফ্রি রিড পাথ) প্রয়োগ করে ডিপ্লয় করেন, এবং দেখেন p99 বেসলাইনে ফিরে আসে যখন Rate উপরে থাকে।

পোস্ট-ইনসিডেন্ট চেকলিস্ট:

• সুনির্দিষ্ট RED লক্ষণ ও সংকুচিত এন্ডপয়েন্ট রেকর্ড করুন।
• প্রোফাইল ও টাইম উইন্ডো সংরক্ষণ করুন।
• নির্দিষ্ট স্যাচুরেশন সিগনালের জন্য এলার্ট যোগ করুন (উদাহরণ: লক ওয়েট/রান কিউ)।
• যদি পুনরায় ঘটে তাহলে পরের প্রশ্ন কী হবে তা লিখে রাখুন।