পারফরম্যান্স টেস্ট ফলাফল থেকে ক্যাপাসিটি প্ল্যানিং
এই পাঠে যা শিখবেন
- ক্যাপাসিটি প্ল্যানিং কী এবং এটি কীভাবে পারফরম্যান্স টেস্টের ফলাফলের উপর নির্ভর করে
- নিরাপত্তা মার্জিন/হেডরুম কেন রাখা হয়
- একটি সহজ সূত্র দিয়ে প্রয়োজনীয় ইনস্ট্যান্স সংখ্যা প্রকৃতপক্ষে গণনা করা
- একাধিক ভিন্ন লোড সিনারিওতে (স্বাভাবিক থেকে পিক পর্যন্ত) এই হিসাব কীভাবে প্রয়োগ করা হয়
১ · পারফরম্যান্স টেস্ট থেকে ক্যাপাসিটি প্ল্যানিং পর্যন্ত
L34-এ যেভাবে একটি একক ইনস্ট্যান্সের প্রকৃত সর্বোচ্চ থ্রুপুট মাপা হয় (স্ট্রেস টেস্টিং দিয়ে, L32 দেখুন), সেই সংখ্যাটিই এখানে ইনপুট হিসেবে ব্যবহার করা হয়। ক্যাপাসিটি প্ল্যানিংCapacity Planningমাপা পারফরম্যান্স ডেটা ব্যবহার করে ভবিষ্যতে প্রত্যাশিত লোড সামলাতে কতটুকু অবকাঠামো (সার্ভার/ইনস্ট্যান্স সংখ্যা) দরকার তা আগে থেকে হিসাব করার প্রক্রিয়া। প্রশ্নটি সহজ: "একটি ইনস্ট্যান্স যদি সর্বোচ্চ X req/s সামলাতে পারে, আর আমাদের Y req/s সামলাতে হয়, তাহলে কতগুলো ইনস্ট্যান্স দরকার?" — কিন্তু বাস্তবে সরাসরি ভাগ করলেই যথেষ্ট নয়।
২ · কেন একটি নিরাপত্তা মার্জিন দরকার
একটি ইনস্ট্যান্সকে তার একদম রেটেড সর্বোচ্চ ক্ষমতায় (১০০%) চালানো ঝুঁকিপূর্ণ — সামান্য অতিরিক্ত ট্রাফিক এলেই, একটি ইনস্ট্যান্স ডাউন হয়ে গেলে, বা মেইনটেন্যান্সের জন্য একটি সাময়িকভাবে সরিয়ে নিলেই পুরো সিস্টেম ওভারলোড হয়ে পড়তে পারে (L32-এর স্ট্রেস/স্পাইক টেস্টিং-এর সাথে সরাসরি সম্পর্কিত)। তাই সাধারণত রেটেড ক্যাপাসিটির একটি অংশ (যেমন ২০%) হেডরুম হিসেবে অব্যবহৃত রাখার পরিকল্পনা করা হয়।
অর্থাৎ প্রতিটি ইনস্ট্যান্সের কার্যকর (usable) ক্ষমতা ধরা হয় রেটেড ক্ষমতার $(1 - \text{safety\_margin})$ ভাগ — বাকিটা বাফার হিসেবে রাখা থাকে।
৩ · তিনটি লোড সিনারিওর জন্য বাস্তব গণনা
ধরা যাক আগের একটি স্ট্রেস টেস্ট থেকে জানা গেছে একটি ইনস্ট্যান্স সর্বোচ্চ ৪৫০ req/s সামলাতে পারে, আর আমরা ২০% হেডরুম রাখতে চাই। নিচের কোড সেলে তিনটি ভিন্ন ভবিষ্যৎ লোড সিনারিওর জন্য — মার্জিনসহ ও মার্জিন ছাড়া, দুই ভাবেই — প্রয়োজনীয় ইনস্ট্যান্স সংখ্যা গণনা করা হয়েছে।
import math
throughput_per_instance = 450 # req/s — একটি স্ট্রেস টেস্ট থেকে মাপা একক-ইনস্ট্যান্স সর্বোচ্চ থ্রুপুট (L32/L34-স্টাইল)
safety_margin = 0.20 # ২০% হেডরুম — রেটেড ক্যাপাসিটির মাত্র ৮০% ব্যবহারযোগ্য বলে ধরা হচ্ছে
effective_capacity = throughput_per_instance * (1 - safety_margin)
scenarios = {
"স্বাভাবিক প্রত্যাশিত লোড": 3000,
"পরিকল্পিত মার্কেটিং ক্যাম্পেইন পিক": 10000,
"ব্ল্যাক ফ্রাইডে-স্টাইল পিক লোড": 25000,
}
print(f"থ্রুপুট/ইনস্ট্যান্স: {throughput_per_instance} req/s | কার্যকর ক্ষমতা ({int((1-safety_margin)*100)}%): {effective_capacity:.1f} req/s\n")
for name, target_load in scenarios.items():
instances_with_margin = math.ceil(target_load / effective_capacity)
instances_no_margin = math.ceil(target_load / throughput_per_instance)
print(f"{name} — টার্গেট {target_load} req/s")
print(f" → নিরাপত্তা মার্জিনসহ প্রয়োজনীয় ইনস্ট্যান্স: {instances_with_margin}")
print(f" → শুধু রেটেড ক্যাপাসিটি ধরলে (মার্জিন ছাড়া): {instances_no_margin}")
print()
ceil-এর কারণে সবসময় পূর্ণসংখ্যায়
উপরের দিকে রাউন্ড হয়ে) বাড়ে।
ক্যাপাসিটি প্ল্যানিং অনুমান নয়, বরং পারফরম্যান্স টেস্টিং থেকে পাওয়া প্রকৃত সংখ্যা (L32-L34) এবং একটি সচেতনভাবে বেছে নেওয়া নিরাপত্তা মার্জিনের উপর ভিত্তি করে করা একটি সরল কিন্তু গুরুত্বপূর্ণ গণনা। M8-এর এই চারটি পাঠ (লোড/স্ট্রেস/সোক/স্পাইক টেস্টিং → পার্সেন্টাইল মেট্রিক্স → বটলনেক শনাক্তকরণ → ক্যাপাসিটি প্ল্যানিং) একসাথে একটি সম্পূর্ণ পারফরম্যান্স-টেস্টিং ওয়ার্কফ্লো তৈরি করে। এরপর M9-এ সিকিউরিটি টেস্টিং শুরু হবে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১
কেন সরাসরি target_load / throughput_per_instance না করে (1 - safety_margin)
দিয়ে ভাগ করা হচ্ছে?
যাতে সিস্টেম কখনো তার একদম রেটেড সর্বোচ্চ ক্ষমতায় না চলে। ৮০%-এর মতো একটি কার্যকর ক্ষমতা ধরে প্ল্যান করলে বাস্তব ট্রাফিক প্রত্যাশার চেয়ে সামান্য বেশি হলে, একটি ইনস্ট্যান্স ব্যর্থ হলে, বা মেইনটেন্যান্সের জন্য একটি সাময়িকভাবে সরিয়ে নিলেও বাকি ইনস্ট্যান্সগুলো ওভারলোড না হয়ে সেই বাড়তি চাপ সামলাতে পারে।
প্র ০২ কোড সেলে স্বাভাবিক লোড সিনারিওতে মার্জিনসহ ৯টি আর মার্জিন ছাড়া ৭টি ইনস্ট্যান্স লাগে — এই ২টি ইনস্ট্যান্সের পার্থক্য বাস্তবে কী প্রতিনিধিত্ব করে?
এই অতিরিক্ত ২টি ইনস্ট্যান্স হলো বাফার ক্ষমতা — স্বাভাবিক সময়ে এগুলো প্রায় অলস থাকে, কিন্তু হঠাৎ ট্রাফিক বেড়ে গেলে বা একটি ইনস্ট্যান্স ব্যর্থ হয়ে গেলে বাকি ইনস্ট্যান্সগুলোর উপর অতিরিক্ত চাপ পড়া ঠেকিয়ে সিস্টেমকে স্থিতিশীল রাখে।
প্র ০৩ L32-এর স্ট্রেস টেস্টিং আর এই ক্যাপাসিটি প্ল্যানিং হিসাবের মধ্যে সম্পর্ক কী?
স্ট্রেস টেস্টিং (L32) হলো সেই প্রক্রিয়া যার মাধ্যমে throughput_per_instance-এর মতো
বাস্তব সংখ্যাটি প্রথমে পাওয়া যায় — একটি ইনস্ট্যান্সকে ধীরে ধীরে লোড বাড়িয়ে তার প্রকৃত ব্রেকিং পয়েন্ট
পর্যন্ত পরীক্ষা করে। ক্যাপাসিটি প্ল্যানিং সেই মাপা সংখ্যাটিকেই ভবিষ্যতের জন্য পরিকল্পনা করতে ব্যবহার করে
— একটি ছাড়া অন্যটি কেবল অনুমানের উপর নির্ভর করত।
অনুশীলন
-
চিন্তা করুন: যদি
safety_margin২০% থেকে বাড়িয়ে ৩৫% করা হয়, স্বাভাবিক লোড (৩০০০ req/s) সিনারিওতে প্রয়োজনীয় ইনস্ট্যান্স সংখ্যা কী হবে?নতুন কার্যকর ক্ষমতা $= 450 \times (1 - 0.35) = 450 \times 0.65 = 292.5$ req/s। প্রয়োজনীয় ইনস্ট্যান্স $= \lceil 3000 / 292.5 \rceil = \lceil 10.26 \rceil = 11$টি — আগের (২০% মার্জিনে) ৯টির চেয়ে ২টি বেশি, কারণ বেশি মার্জিন মানে প্রতি ইনস্ট্যান্সের কার্যকর ক্ষমতা কম, তাই একই টার্গেট লোড সামলাতে আরও বেশি ইনস্ট্যান্স লাগে।
-
পরীক্ষা করুন: কোড সেলের
scenariosডিকশনারিতে একটি নতুন এন্ট্রি যোগ করুন:"ভাইরাল ইভেন্ট": 50000— এবং Run চেপে প্রয়োজনীয় ইনস্ট্যান্স সংখ্যা দেখুন।কার্যকর ক্ষমতা ৩৬০ req/s ধরে, প্রয়োজনীয় ইনস্ট্যান্স $= \lceil 50000 / 360 \rceil = \lceil 138.89 \rceil = 139$টি। এটি দেখায় কীভাবে একই সূত্র যেকোনো টার্গেট লোডের জন্য — এমনকি চরম, অপ্রত্যাশিত পিকের জন্যও — সরাসরি প্রযোজ্য, কোনো নতুন লজিক ছাড়াই।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরের পাঠ L36 সিকিউরিটি টেস্টিং ফান্ডামেন্টাল — M9 সিকিউরিটি টেস্টিং মডিউল শুরু হচ্ছে।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ টেস্ট ডিজাইন টেকনিক, ইউনিট টেস্টিং, টেস্ট ডাবলস, ইন্টিগ্রেশন টেস্টিং, কভারেজ, অটোমেশন, পারফরম্যান্স ও সিকিউরিটি টেস্টিং, অ্যাডভান্সড টেকনিক ও CI/CD ইন্টিগ্রেশন — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks, Mobile App Development, Ethics in Computing & AI Safety ও Software Testing & Quality Assurance — সব এক জায়গায়।