2.16 পারফরম্যান্স প্রকৌশল

পরিচিতি ও প্রেরণা

পারফরম্যান্স প্রকৌশল হলো সহজাত বোধের বদলে পরিমাপ ব্যবহার করে সুচিন্তিতভাবে কোডকে যথেষ্ট দ্রুত করার শিল্প। এই অধ্যায় কোড ও উপাদানের স্তরে কাজ করে: ফাংশন, লুপ, ডেটা স্ট্রাকচার, কোয়েরি, অ্যালোকেশন এবং একটি একক সার্ভিস কীভাবে তার সময় ব্যয় করে। এটি অধ্যায় 3.5-এর সঙ্গী, যা সিস্টেম স্তরে পারফরম্যান্স সামলায় (স্কেল আউট, লোড ব্যালান্সিং, সক্ষমতা ও স্থিতিস্থাপকতা)। সিস্টেম ধীর হলে অধ্যায় 3.5 জিজ্ঞেস করে আপনার কয়টি মেশিন লাগবে; এই অধ্যায় জিজ্ঞেস করে একটি মেশিন প্রথমেই এত কাজ কেন করছে। সাধারণত আপনার দুটিই লাগবে, এবং কোড-স্তরের দৃশ্যেই চমকপ্রদ পরিমাণ খরচ ও লেটেন্সি আসলে লুকিয়ে থাকে।

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

এন্টারপ্রাইজের জন্য পারফরম্যান্স অর্থ: দ্রুততর কোড মানে কম মেশিন, কম ক্লাউড বিল, এবং অতিরিক্ত জোগান ছাড়াই লেটেন্সিতে একটি সেবা-স্তরের চুক্তি (SLA) পূরণের সামর্থ্য। সরকারের জন্য পারফরম্যান্স প্রবেশাধিকার: দুর্বল মোবাইল সংযোগে পুরোনো ফোনে লোড হওয়া একটি পাতা একজন নাগরিকের সুবিধার দাবি সম্পন্ন করা এবং হাল ছেড়ে দেওয়ার পার্থক্য। সরকারি সিস্টেমের পুনরুৎপাদনযোগ্য বেঞ্চমার্ক প্রমাণও দরকার, কারণ ক্রয় ও তদারকি সংস্থা আপনাকে সংখ্যা প্রমাণ করতে বলবে, কেবল দাবি নয়।

মূল নীতিসমূহ

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

সুপারিশ

আগে মাপুন, এবং একটি লাইন ছোঁয়ার আগে প্রোফাইল করুন

এই ক্ষেত্রের সবচেয়ে পুরোনো নিয়ম সবচেয়ে বেশি উপেক্ষিত: অপ্টিমাইজের আগে বাধা খুঁজে বের করুন। একটি প্রোফাইলার ধরুন, এমন একটি টুল যা একটি চলমান প্রোগ্রাম নমুনা বা যন্ত্রসজ্জা করে দেখায় সে কোথায় সময় ও মেমরি ব্যয় করে। CPU (কোন ফাংশন চক্র পোড়ায়), মেমরি ও অ্যালোকেশন (কী কতবার বরাদ্দ হয়, কারণ অ্যালোকেশনের ঘূর্ণি গার্বেজ-কালেকশন বিরতি চালায়), এবং I/O (ডিস্ক, নেটওয়ার্ক বা ডেটাবেসের অপেক্ষায় ব্যয়িত সময়) প্রোফাইল করুন। একটি ফ্লেম গ্রাফ, একটি স্তূপীকৃত দৃশ্য যেখানে প্রতিটি বাক্স একটি ফাংশন এবং তার প্রস্থ ব্যয়িত সময়, প্রধান খরচ এক নজরে স্পষ্ট করে: গভীরতম স্ট্যাক নয়, প্রশস্ততম বাক্স খুঁজুন। আগে সবচেয়ে বড় খরচ অপ্টিমাইজ করুন, আবার মাপুন, এবং বাজেটে পৌঁছালে থামুন। এটি অধ্যায় 9.2-এর অবজার্ভেবিলিটি চর্চার সঙ্গে যুক্ত, কারণ একটি প্রোডাকশন প্রোফাইল ল্যাপটপ থেকে করা যেকোনো আন্দাজকে হারায়।

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

পারফরম্যান্স বাজেট দিয়ে “যথেষ্ট দ্রুত” মানে কী সংজ্ঞায়িত করুন

গতি বিমূর্তে কোনো গুণ নয়; এটি একটি লক্ষ্য যা আপনি হয় পূরণ করেন, নয়তো ফসকান। একটি পারফরম্যান্স বাজেট ঠিক করুন: “p99 চেকআউট লেটেন্সি ৩০০ মিলিসেকেন্ডের নিচে” বা “এই এন্ডপয়েন্ট প্রতি অনুরোধে ১ MB-র নিচে বরাদ্দ করে”-র মতো একটি সুনির্দিষ্ট সীমা। এটি ব্যবহারকারী বা ব্যবসা অনুভব করে এমন কিছুর সঙ্গে বাঁধুন, এবং পার্সেন্টাইল হিসেবে প্রকাশ করুন, গড় নয়, কারণ গড় ধীর লেজ লুকায় যেখানে প্রকৃত ব্যবহারকারীরা বাস করেন। ১% অনুরোধ ৫ সেকেন্ড নিলে আপনার গড় ঠিক দেখাতে পারে অথচ গ্রাহকদের একটি অর্থপূর্ণ অংশ ভোগে। বাজেট একটি দলকে “সম্পন্ন”-র ভাগ করা, অবিতর্কিত সংজ্ঞা এবং এমন একটি রেখা দেয় যা একটি রিগ্রেশন দৃশ্যমানভাবে পেরোয়।

মাইক্রো-অপ্টিমাইজেশনের আগে অ্যালগরিদমিক দক্ষতার কাছে যান

সবচেয়ে বড়, সবচেয়ে সস্তা জয় আসে অ্যালগরিদমিক দক্ষতা থেকে, ইনপুট বাড়লে কাজ কীভাবে বাড়ে, যা বিগ-ও নোটেশন দিয়ে বর্ণিত (বৃদ্ধির হার শ্রেণিবদ্ধ করার উপায়, ফলে O(n log n) সর্ট O(n স্কোয়ার)-এর চেয়ে অনেক ভালো বড় হয়)। দশটি আইটেমে অদৃশ্য একটি নেস্টেড লুপ দশ হাজারে বিপর্যয় হয়ে ওঠে। হট ফাংশন হাতে-টিউন করার আগে জিজ্ঞেস করুন এটি মৌলিকভাবে অতিরিক্ত কাজ করছে কি না: একটি আকস্মিক N+1 কোয়েরি, হ্যাশ খোঁজ হওয়া উচিত এমন একটি রৈখিক স্ক্যান, বা মেমোইজ করা যেত এমন পুনরাবৃত্ত কাজ। এটি অধ্যায় 2.13-এর অ্যালগরিদমিক ভিত্তির সঙ্গে যুক্ত। ধ্রুবক-গুণক টিউনিংয়ের কোনো পরিমাণ ভুল জটিলতা শ্রেণিকে উদ্ধার করে না।

লেটেন্সি ও থ্রুপুট আলাদা করুন, এবং লেজকে সম্মান করুন

লেটেন্সি হলো একটি অপারেশনে কত সময় লাগে; থ্রুপুট হলো প্রতি একক সময়ে কতগুলো অপারেশন সম্পন্ন হয়। এগুলো এক লক্ষ্য নয়, এবং একটি অপ্টিমাইজ করা অন্যটি ক্ষতি করতে পারে। ব্যাচিং থ্রুপুট উন্নত করে কিন্তু ব্যাচের প্রথম আইটেমে লেটেন্সি যোগ করে; সমান্তরাল ওয়ার্কার যোগ থ্রুপুট বাড়ায় কিন্তু কনটেনশনের মাধ্যমে লেজের লেটেন্সি খারাপ করতে পারে। ঠিক করুন আপনার ব্যবহারকারীদের আসলে কোনটি দরকার। এবং সবসময় লেজের দিকে নজর রাখুন: p95 ও p99 লেটেন্সি, সবচেয়ে ধীর ৫% ও ১% অনুরোধ, কারণ বড় পরিসরে একজন ব্যবহারকারী বহু অনুরোধ করেন এবং প্রায়ই লেজে পড়েন। পার্সেন্টাইল জানান, তার ওপর অ্যালার্ট দিন এবং তার জন্য বাজেট করুন।

সমান্তরালতার সীমা জানুন

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

ক্যাশিং ও ডেটা লোকালিটি ব্যবহার করুন, এবং তাদের খরচ সম্মান করুন

একটি ক্যাশ, সাম্প্রতিক বা ব্যয়বহুলভাবে গণনা করা ফলাফলের দ্রুত ভাণ্ডার, আপনার হাতের সবচেয়ে শক্তিশালী পারফরম্যান্স হাতিয়ার এবং সবচেয়ে বিপজ্জনক। Phil Karlton-এর রসিকতা যে কম্পিউটার বিজ্ঞানের দুটি কঠিন সমস্যা ক্যাশ অকার্যকরকরণ ও নামকরণ একটি সতর্কতা: সেকেলে ক্যাশ ভুল উত্তর দেয়, এবং অকার্যকরকরণ যুক্তিতে সূক্ষ্ম ত্রুটির জন্ম। সুচিন্তিতভাবে ক্যাশ করুন, মেয়াদ ঠিক করুন, এবং হিট রেট অপ্টিমাইজের আগে আপনার সঠিকতার গল্প জানুন। সর্বনিম্ন স্তরে রেফারেন্সের লোকালিটি, একসঙ্গে ব্যবহৃত ডেটা মেমরিতে কাছাকাছি রাখা, CPU ক্যাশ শ্রেণিবিন্যাস কাজে লাগায় এবং ক্যাশ মিসকে হিটে পরিণত করে কোনো অ্যালগরিদমিক পরিবর্তন ছাড়াই কোডকে কয়েক গুণ দ্রুত করতে পারে। এই কারণে পয়েন্টার-তাড়া করা কাঠামোর চেয়ে সংলগ্ন অ্যারে ভালো। এটি অধ্যায় 3.4-এর ডেটা বিন্যাস পছন্দের সঙ্গে ছেদ করে।

সৎভাবে বেঞ্চমার্ক করুন এবং মাইক্রোবেঞ্চমার্ককে অবিশ্বাস করুন

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

CI-তে পারফরম্যান্স গেট করুন এবং প্রোডাকশনে লক্ষ্য রাখুন

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতি	সুবিধা	অসুবিধা
এখনই অন্তর্দৃষ্টির ভিত্তিতে অপ্টিমাইজ	উৎপাদনশীল মনে হয়; মাঝেমধ্যে ভাগ্যবান জয়	সাধারণত ভুল কোড টিউন করে; লাভ ছাড়া জটিলতা যোগ করে
আগে মাপুন, তারপর অপ্টিমাইজ	প্রকৃত বাধা লক্ষ্য করে; প্রমাণভিত্তিক	টুলিং ও শৃঙ্খলা লাগে; শুরুতে ধীর
ক্যাশিং	বড় লেটেন্সি ও থ্রুপুট লাভ	অকার্যকরকরণ ত্রুটি; সেকেলে ডেটা; মেমরি খরচ
আরও সমান্তরালতা	সমান্তরাল কাজে উচ্চতর থ্রুপুট	অ্যামডালের সীমা; কনটেনশন; কনকারেন্সি ত্রুটি
মাইক্রো-অপ্টিমাইজেশন	ধ্রুবক গুণক নিঙড়ায়	ক্ষুদ্র সীমা; পাঠযোগ্যতা ক্ষতি করে; প্রায়ই গোলমাল
অ্যালগরিদমিক উন্নতি	লাভ ইনপুটের আকারের সঙ্গে বাড়ে	বিশ্লেষণ লাগে; কখনো বড় পুনর্লিখন
CI পারফরম্যান্স গেট	রিগ্রেশন আগে ও সস্তায় থামায়	অস্থির বেঞ্চমার্ক বিশ্বাস ক্ষয় করে; স্থিতিশীল পরিবেশ লাগে

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. আপনার গুরুত্বপূর্ণ পথের জন্য কি একটি লিখিত পারফরম্যান্স বাজেট আছে, এবং তা কি পার্সেন্টাইল হিসেবে প্রকাশিত? অনেক দলের একটি ঝাপসা বোধ আছে যে জিনিস “দ্রুত” হওয়া উচিত কিন্তু এমন কোনো সংখ্যা নেই যার বিপরীতে কেউ ব্যর্থ হতে পারে, মানে ভাঙা পর্যন্ত পারফরম্যান্স কারও কাজ নয়। “p99 ৩০০ মিলিসেকেন্ডের নিচে”-র মতো বাজেট লক্ষ্যকে সুনির্দিষ্ট করে, পর্যালোচকদের প্রয়োগ করার কিছু দেয়, এবং রিগ্রেশনকে ধীর পিছলের বদলে দৃশ্যমান ঘটনা করে। বড় দলে এটি সবচেয়ে গুরুত্বপূর্ণ, যেখানে লেটেন্সি বহু হাতের মধ্য দিয়ে ঢোকে এবং কোনো একক রচয়িতা জমা খরচ দেখেন না। আপনার বর্তমান লেটেন্সি তথ্য আনুন এবং জিজ্ঞেস করুন আপনি কি গড় জানাচ্ছেন, যা তোষামোদ করে, নাকি পার্সেন্টাইল, যা সত্য বলে। “যথেষ্ট দ্রুত” মানে কী একটি সংখ্যা হিসেবে বলতে না পারলে সেটিই ঠিক করার প্রথম বিষয়।

2. আপনি শেষবার কিছু অপ্টিমাইজ করার সময় কি প্রোফাইলার আপনাকে কোথায় দেখতে হবে বলেছিল, নাকি আপনি আন্দাজ করেছিলেন? বাধা কুখ্যাতভাবে অভিজ্ঞ ইঞ্জিনিয়াররা যেখানে আশা করেন সেখানে নয়, এবং ভুল কোড টিউনে ব্যয় করা সময় দুবার হারানো, একবার কাজে এবং একবার যোগ করা জটিলতায়। যে সংস্কৃতি আগে প্রোফাইল করে সে তার পরিশ্রম সেখানে ব্যয় করে যেখানে ফল দেয় এবং স্পষ্ট কোড একা ছেড়ে দেয়। আপনার দলকে সাম্প্রতিক তিনটি পারফরম্যান্স সমাধান মনে করতে বলুন এবং প্রতিটি পরিমাপ থেকে শুরু হয়েছিল নাকি আন্দাজ থেকে। ভাবুন আপনি প্রোডাকশনে বা বাস্তবসম্মত স্টেজিংয়ে প্রোফাইল করতে পারেন কি না, কারণ একটি ল্যাপটপ প্রোফাইল ভীষণভাবে বিভ্রান্ত করতে পারে। উত্তর প্রকাশ করে আপনার পারফরম্যান্স কাজ প্রকৌশল নাকি লোককথা।

3. আজ কী একটি পারফরম্যান্স রিগ্রেশনকে প্রোডাকশনে পৌঁছানো থেকে ঠেকায়? বর্ধমান দলে সৎ উত্তর প্রায়ই “একজন গ্রাহকের অভিযোগ”, মানে ব্যবহারকারীরাই আপনার রিগ্রেশন টেস্ট। একটি CI গেট যা কোনো বেঞ্চমার্ক বা বাজেট খারাপ হলে বিল্ড ব্যর্থ করে সমস্যা ধরে যখন সারানো সস্তা এবং রচয়িতা এখনো পরিবর্তনটি মনে রাখেন। আলোচনা করুন আপনার বেঞ্চমার্ক গেট করার মতো যথেষ্ট স্থিতিশীল কি না, কারণ নেকড়ের ডাক দেওয়া অস্থির পারফরম্যান্স টেস্ট উপেক্ষিত বা নিষ্ক্রিয় হবে। প্রোডাকশনে আপনি কী লক্ষ্য রাখেন তা নিয়েও কথা বলুন, কারণ কিছু রিগ্রেশন কেবল প্রকৃত ট্রাফিক ও ডেটায় দেখা দেয়। লক্ষ্য হলো পারফরম্যান্সকে এমন বৈশিষ্ট্য করা, যা সিস্টেম স্বয়ংক্রিয়ভাবে রক্ষা করে, ঘটনায় পুনরায় আবিষ্কার করা কিছু নয়।

4. আপনি কি প্রতিটি গুরুত্বপূর্ণ পথে লেটেন্সি নাকি থ্রুপুটের জন্য অপ্টিমাইজ করেন, এবং কেউ কি সেই পছন্দ লিখে রেখেছে? এগুলো ভিন্ন লক্ষ্য যা বিপরীত দিকে টানে: ব্যাচিং ও সমান্তরাল ওয়ার্কার থ্রুপুট তোলে কিন্তু পৃথক অনুরোধে লেটেন্সি যোগ করতে পারে, তাই সহজাত বোধে অপ্টিমাইজ করা দল প্রায়ই ভুল অক্ষ কেনে এবং কেউ যার অভাবে ছিল না এমন মেশিন সময় বাঁচাতে ব্যবহারকারীদের অপেক্ষা করায়। বড় দলে বিপদ গুণ হয়, কারণ একটি গোষ্ঠী একটি ভাগ করা সার্ভিস বাল্ক থ্রুপুটের জন্য টিউন করে যখন আরেকটি তার ওপর ইন্টারঅ্যাক্টিভ লেটেন্সির জন্য নির্ভর করে, আর কেউ অন্যের লক্ষ্য জানে না। প্রতিটি পথের প্রকৃত ব্যবহারের ধরন (ইন্টারঅ্যাক্টিভ অনুরোধ বনাম ব্যাকগ্রাউন্ড ব্যাচ), বর্তমান পার্সেন্টাইল লেটেন্সি এবং আপনার দরকারি টেকসই থ্রুপুট আনুন, তারপর একটি ডিফল্ট ফুটে ওঠার বদলে অক্ষ সুস্পষ্টভাবে ঠিক করুন। SLA-র অধীনে এন্টারপ্রাইজ বা সরকারি সিস্টেমের জন্য নাম দিন চুক্তি কোন মেট্রিকের বিপরীতে লেখা, কারণ অপরিমিত অক্ষ অপ্টিমাইজ করা আপনার ড্যাশবোর্ড সুস্থ দেখালেও চুক্তি ভাঙতে পারে।

5. আপনার বেঞ্চমার্ক যে প্রকৃত কাজ মাপে, অপ্টিমাইজার আপনার টেস্ট মুছে ফেলছে না, তা আপনি কীভাবে জানেন? যে বেঞ্চমার্ক মিথ্যা বলে তা না থাকার চেয়েও খারাপ, কারণ তা দলকে মিথ্যা আস্থা দেয় এবং তারপরও একটি রিগ্রেশন পাঠানো হয়। দলগুলো নিয়মিত একটি খেলনা ইনপুটে ঠান্ডা রান থেকে একটি একক ভাগ্যবান সংখ্যা জানায়, যা স্টার্টআপ, জাস্ট-ইন-টাইম কম্পাইলেশন এবং অব্যবহৃত কোড সরানোর কম্পাইলারের সামর্থ্য মাপে, ব্যবহারকারীরা আসলে যে আচরণের মুখোমুখি হন তা নয়। একটি উদাহরণ বেঞ্চমার্ক আনুন এবং জেরা করুন: এটি কি ওয়ার্ম আপ করে, অনেক পুনরাবৃত্তি চালায়, ভিন্নতা জানায়, প্রতিনিধিত্বমূলক ডেটার আকার ও বণ্টন ব্যবহার করে, এবং তার ফলাফলে ডেড-কোড-অপসারণ ঠেকায়। প্রতিদ্বন্দ্বী টান হলো সৎ বেঞ্চমার্ক দ্রুত মাইক্রোবেঞ্চমার্কের চেয়ে লিখতে ও চালাতে ধীর, তাই একমত হন কোথায় সস্তা আনুমানিকতা গ্রহণযোগ্য আর কোথায় আপনি কঠোরতা দাবি করেন। যে সরকারি বা নিয়ন্ত্রিত পরিবেশে ক্রয় ও তদারকি সংস্থা আপনাকে সংখ্যা পুনরুৎপাদন করতে বলবে, সেখানে ফলাফলের পাশে ডিভাইস, ওয়ার্কলোড ও পরিবেশ ধরে রাখুন, যাতে দাবি কেবল দাবি না হয়ে যাচাই করা যায়।

6. পারফরম্যান্সের কাজ যখন একই ইঞ্জিনিয়ারদের জন্য ফিচারের সঙ্গে প্রতিযোগিতা করে, তখন কীভাবে ঠিক করেন, এবং বাজেটের কর্তৃত্ব কার? পারফরম্যান্সে প্রতিদান তীব্রভাবে কমে, তাই প্রথম প্রোফাইল-চালিত সমাধান লেটেন্সি অর্ধেক করতে পারে আর দশমটি দ্বিগুণ কোডের জটিলতায় এক শতাংশ কাটে, এবং নিয়ম ছাড়া সবচেয়ে জোরালো কণ্ঠ বা নিকটতম সময়সীমা জেতে। প্রতিদ্বন্দ্বী বিবেচনা প্রকৃত: অসমাধানকৃত পারফরম্যান্স ঋণ নিঃশব্দে চক্রবৃদ্ধি হয় এবং পরে জুড়তে আরও ব্যয়বহুল, তবু বাজেটের বাইরে গতির পেছনে ছোটা রোডম্যাপকে অনাহারে রাখে এবং ভবিষ্যৎ কাজ ধীর করা জটিলতা যোগ করে। প্রতিটি গুরুত্বপূর্ণ পথের বর্তমান বাজেট অবস্থা, স্থিতাবস্থার আনুমানিক খরচ মেশিন বা হারানো রূপান্তরে, এবং পরবর্তী অপ্টিমাইজেশনের প্রান্তিক প্রতিদান আনুন, যাতে বিনিময় চাপের বদলে প্রমাণে করা হয়। একটি বড় এন্টারপ্রাইজ বা সরকারি কর্মসূচির জন্য নাম দিন পারফরম্যান্স বাজেটের মালিক কে এবং কে তার বিরুদ্ধে প্রকৌশল সময় ব্যয় অনুমোদন করতে পারেন, কারণ যে লক্ষ্য রক্ষার জন্য কেউ জবাবদিহিযোগ্য নয় তা নিঃশব্দে ক্ষয়ে যায়।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। সরবরাহের গতি প্রক্রিয়াকে হারায়, তাই পুনর্লিখন ও মহান পারফরম্যান্স ফ্রেমওয়ার্ক প্রতিরোধ করুন। ব্যবহারকারীরা সত্যিই যে পথ নিয়ে অভিযোগ করেন সেখানে একটি বিকেল প্রোফাইলারের সঙ্গে কাটান, সবচেয়ে বড় খরচ সারান (প্রায়ই একটি N+1 কোয়েরি বা আকস্মিক রৈখিক স্ক্যান), এবং CI-তে একটি হালকা পার্সেন্টাইল বাজেট যোগ করুন যাতে জয়টি নিঃশব্দে পিছিয়ে যেতে না পারে। গভীর অপ্টিমাইজেশন সংরক্ষণ করুন সেই মুহূর্তের জন্য, যখন একটি প্রকৃত সংখ্যা, আন্দাজ নয়, বলে কোড খুব ধীর।

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

এন্টারপ্রাইজ। বহর পরিসরে পারফরম্যান্স সরাসরি খরচ, তাই একে ভাগ করা শৃঙ্খলা হিসেবে নিয়ন্ত্রণ করুন: প্রমিত প্রোফাইলিং টুল, ব্যবসায়িক মেট্রিকের সঙ্গে বাঁধা পার্সেন্টাইল বাজেট, এবং সামঞ্জস্যপূর্ণভাবে প্রযুক্ত CI রিগ্রেশন গেট, যাতে কোনো একক দলের ধীর অনুপ্রবেশ পুরো ক্লাউড বিল ফোলায় না। সার্ভিস জুড়ে ভিত্তিরেখার বিপরীতে লেটেন্সি, অ্যালোকেশন ও থ্রুপুট অনুসরণ করুন, এবং পুনরুৎপাদনযোগ্য বেঞ্চমার্ক প্রমাণ রাখুন, কারণ একটি বড় বহরে ৩০% CPU হ্রাস একটি পুনরাবৃত্ত সঞ্চয় যা নিরীক্ষণ ও SLA জরিমানার বিরুদ্ধে রক্ষা করার যোগ্য।

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

উদাহরণ

স্টার্টআপ। একটি ছোট SaaS দল লক্ষ্য করে তাদের ড্যাশবোর্ড মন্থর অনুভূত হচ্ছে এবং একটি দ্রুততর ফ্রেমওয়ার্কে পুনর্লিখনে প্রলুব্ধ হয়। তার বদলে তারা একটি প্রোফাইলার ও ফ্লেম গ্রাফ নিয়ে একটি বিকেল কাটায়, যা দেখায় অনুরোধের সময়ের ৭০% একটি এন্ডপয়েন্টে, যা প্রতি সারিতে একটি ডেটাবেস কোয়েরি করে, ক্লাসিক N+1 ধরন। তারা তা একটি ব্যাচ কোয়েরিতে প্রতিস্থাপন করে, লেটেন্সি ১.২ সেকেন্ড থেকে ৯০ মিলিসেকেন্ডে নামে, এবং সমাধান যাতে নিঃশব্দে পিছিয়ে না যায় সেজন্য একটি হালকা CI বেঞ্চমার্কে ২০০ মিলিসেকেন্ডের p99 বাজেট যোগ করে। কোনো পুনর্লিখন নেই, একটি বিকেল, দশ গুণ জয়।

এন্টারপ্রাইজ। একটি খুচরা প্ল্যাটফর্ম হাজার হাজার ইনস্ট্যান্স চালায়, এবং তার ক্লাউড বিলে একটি সুপারিশ সার্ভিস প্রধান। একটি প্রোফাইলিং অভিযান ঘন ঘন গার্বেজ-কালেকশন বিরতি ঘটানো ভারী অ্যালোকেশন ঘূর্ণি এবং খারাপ হিট রেটের একটি ক্যাশ খুঁজে পায়। লোকালিটির জন্য ডেটা স্ট্রাকচার টিউন এবং ক্যাশ কী সারানো প্রতি অনুরোধে CPU ৪০% কমায়, যা দলকে একই ট্রাফিক ৪০% কম মেশিনে চালাতে দেয়। সঞ্চয় সপ্তাহের মধ্যে প্রকৌশল পরিশ্রমের খরচ তোলে, এবং মাঝেমধ্যে লঙ্ঘিত একটি p99 লেটেন্সি SLA এখন আরামে টিকে, চুক্তিগত জরিমানা এড়িয়ে।

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

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

পারফরম্যান্স প্রকৌশলের প্রতিদান তিনটি খাতায় দেখা দেয়। প্রথমটি অবকাঠামো খরচ: দ্রুততর কোড কম মেশিনে একই কাজ করে, এবং একটি বড় বহরের জন্য ৩০% CPU হ্রাস একটি সরাসরি, পুনরাবৃত্ত সঞ্চয় যা এককালীন প্রকৌশল পরিশ্রমকে বামন করে। দ্বিতীয়টি রাজস্ব ও সন্তুষ্টি: লেটেন্সি রূপান্তর, পরিত্যাগ ও ব্যবহারকারীর বিশ্বাসের সঙ্গে সম্পর্কিত, তাই লেজ কাটা শুধু স্বাস্থ্যবিধির কাজ নয়, একটি প্রবৃদ্ধির লিভার। তৃতীয়টি এড়ানো ঝুঁকি: একটি SLA লঙ্ঘন জরিমানা বহন করে, এবং লোডে গলে যাওয়া একটি লঞ্চ সুনামের ক্ষতি ও অগ্নিনির্বাপণের খরচ বহন করে।

মালিকানার মোট খরচ মাঝারি এবং সামনে-ভারী। আপনি প্রোফাইলিং টুল, একটি স্থিতিশীল বেঞ্চমার্কিং পরিবেশ এবং CI গেটে বিনিয়োগ করেন, সঙ্গে বাজেট লেখার ও প্রোফাইল পড়ার শৃঙ্খলা। বড়, লুকানো খরচ হলো বিকল্প: পারফরম্যান্স ঋণ নিঃশব্দে চক্রবৃদ্ধি হয়, এবং লঞ্চের পরে ধীর সিস্টেমে গতি জুড়ে দেওয়া তা নিরন্তর রক্ষা করার চেয়ে অনেক বেশি ব্যয়বহুল। নেতৃত্বের কাছে যুক্তি দিন তাঁদের নিজস্ব এককে। লেটেন্সিকে রূপান্তর বা নাগরিকের সমাপ্তির হারে অনুবাদ করুন, CPU-কে মাসিক ক্লাউড ব্যয়ে অনুবাদ করুন, এবং একটি রিগ্রেশন গেটকে এড়ানো ঘটনায় অনুবাদ করুন। সবচেয়ে শক্তিশালী যুক্তি হলো পারফরম্যান্স কমিট ধরে ধরে রক্ষা করা সস্তা আর পচে যাওয়ার পর পুনরুদ্ধার করা সর্বনাশা।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

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

পরিপক্বতা মডেল

• স্তর ১, সূচনা: পারফরম্যান্স সম্বোধিত হয় কেবল কিছু ভাঙলে। কোনো বাজেট নেই, প্রোফাইলিংয়ের অভ্যাস নেই, বেঞ্চমার্ক নেই। অপ্টিমাইজেশন সহজাত বোধে চালিত অনুমান, এবং গড় একমাত্র মেট্রিক যা কেউ জানায়।
• স্তর ২, বিকাশ: কিছু দল ঘটনার সময় প্রোফাইল করে এবং কয়েকটি বেঞ্চমার্ক রাখে, কিন্তু চর্চা অসঙ্গত এবং ব্যক্তিগত উৎসাহের ওপর নির্ভর করে। এক-দুটি গুরুত্বপূর্ণ পথের জন্য বাজেট অনানুষ্ঠানিকভাবে আছে এবং কিছু ড্যাশবোর্ডে পার্সেন্টাইল দেখা যায়, তবু কিছুই একটি রিগ্রেশন পাঠানোর আগে গেট করে না এবং প্রতিটি দল নিজের পদ্ধতি পুনরাবিষ্কার করে।
• স্তর ৩, মানসম্মতকরণ: গুরুত্বপূর্ণ পথ লিখিত পার্সেন্টাইল বাজেট বহন করে, এবং কেউ অপ্টিমাইজ করার আগে প্রোফাইলিং নথিবদ্ধ, প্রত্যাশিত প্রথম ধাপ। CI-তে রিগ্রেশন গেটসহ পারফরম্যান্স টেস্ট আছে, সৎ বেঞ্চমার্কিং নিয়ম (ওয়ার্ম-আপ, ভিন্নতা, প্রতিনিধিত্বমূলক ডেটা) লিখিত ও প্রতিষ্ঠানজুড়ে বলবৎ, এবং প্রতিটি দল নিজস্ব নয়, একই পদ্ধতি অনুসরণ করে।
• স্তর ৪, ব্যবস্থাপনা: প্রতিষ্ঠান পারফরম্যান্স নিয়ন্ত্রিত বৈশিষ্ট্য হিসেবে মাপে। লেটেন্সি পার্সেন্টাইল, থ্রুপুট, অ্যালোকেশন হার ও ধীর-কোয়েরির সংখ্যা প্রোডাকশন ও CI-তে সুস্পষ্ট ভিত্তিরেখার বিপরীতে অনুসরণ করা হয়, রিগ্রেশন তর্কের বদলে সীমার বিপরীতে পরিমাণযোগ্য, এবং বাজেট রূপান্তর বা ক্লাউড ব্যয়ের মতো ব্যবসায়িক মেট্রিকের সঙ্গে বাঁধা, তাই লঙ্ঘন একটি তথ্য-সমর্থিত সিদ্ধান্ত ট্রিগার করে। বেঞ্চমার্ক প্রমাণ অডিটের জন্য ডিভাইস, ওয়ার্কলোড ও পরিবেশসহ পুনরুৎপাদনযোগ্য ও ধরা।
• স্তর ৫, সমন্বয়: পারফরম্যান্স নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে একীভূত। বাজেট, প্রোফাইলিং, সৎ বেঞ্চমার্কিং ও ফ্লেম-গ্রাফ বিশ্লেষণ রুটিন দক্ষতা, রিগ্রেশন গেট স্থিতিশীল ও বিশ্বস্ত, এবং প্রোডাকশন ও CI তথ্য স্বয়ংক্রিয়ভাবে চক্র বন্ধ করে। ট্রাফিক, হার্ডওয়্যার ও ব্যবসায়িক অগ্রাধিকার সরলে প্রতিষ্ঠান বাজেট খাপ খাওয়ায়, যেখানে প্রতিদান সর্বোচ্চ সেই পথে প্রচেষ্টা পুনর্ভারসাম্যে আনে, এবং পারফরম্যান্সকে পর্যায়ক্রমিক অভিযানের বদলে স্থায়ী বৈশিষ্ট্য হিসেবে রক্ষা করে।

আলোচনার ভাবনা

1. আপনার কোন গুরুত্বপূর্ণ পথের আজ লিখিত, পার্সেন্টাইল-ভিত্তিক বাজেট আছে, আর কোনগুলো কেবল আশায় রক্ষিত?
2. একটি প্রোফাইলার আপনাকে শেষবার কখন অবাক করেছে, এবং সময় কোথায় যায় বলে আপনি ধরে নেন সে সম্পর্কে তা আপনাকে কী শিখিয়েছে?
3. আপনার বেঞ্চমার্ক কি ওয়ার্ম আপ করে, ভিন্নতা জানায় এবং প্রতিনিধিত্বমূলক ডেটা ব্যবহার করে, নাকি অপ্টিমাইজারকে মাপছে?
4. যে কোড একটি প্রোফাইলিং অভিযান সস্তা করতে পারত তা ঢাকতে আপনি কোথায় মেশিন খরচ করছেন?
5. আপনার সবচেয়ে সমান্তরাল ওয়ার্কলোডের ক্রমিক ভগ্নাংশ কত, এবং অ্যামডালের সূত্র কি আপনার তাড়া করা গতিবৃদ্ধিকে সীমিত করে?
6. কোনো সতীর্থ p99 লেটেন্সি দ্বিগুণ করা একটি পরিবর্তন মার্জ করলে কেউ লক্ষ্য করতে কত সময় লাগত, এবং তারা কীভাবে জানত?

প্রধান শিক্ষা

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

তথ্যসূত্র ও আরও পড়ার জন্য

• Brendan Gregg, Systems Performance: Enterprise and the Cloud (প্রোফাইলিং, ফ্লেম গ্রাফ ও পদ্ধতি)।
• Brendan Gregg, BPF Performance Tools (Linux-এ ব্যবহারিক অবজার্ভেবিলিটি ও প্রোফাইলিং)।
• Donald E. Knuth, “Structured Programming with go to Statements” (ACM Computing Surveys, 1974): অকালপক্ব-অপ্টিমাইজেশনের প্রবাদের উৎস।
• Donald E. Knuth, The Art of Computer Programming (অ্যালগরিদমিক বিশ্লেষণ ও জটিলতা)।
• Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest ও Clifford Stein, Introduction to Algorithms (বিগ-ও ও অ্যালগরিদমিক দক্ষতা)।
• Gene M. Amdahl, “Validity of the Single Processor Approach to Achieving Large-Scale Computing Capabilities” (1967): অ্যামডালের সূত্রের উৎস।
• Ulrich Drepper, “What Every Programmer Should Know About Memory” (মেমরি শ্রেণিবিন্যাস ও ডেটা লোকালিটি)।
• Martin Kleppmann, Designing Data-Intensive Applications (সিস্টেমে লেটেন্সি, থ্রুপুট ও লেজ আচরণ)।
• Aleksey Shipilev, “JMH and the pitfalls of microbenchmarking” (ম্যানেজড রানটাইমে সৎ বেঞ্চমার্কিং চর্চা)।
• Ilya Grigorik, High Performance Browser Networking (নিম্ন-ব্যান্ডউইথ ব্যবহারকারীদের জন্য ক্লায়েন্ট-সাইড ও নেটওয়ার্ক পারফরম্যান্স)।