Load Testing: load, stress, spike ও soak test

এই পাঠে যা শিখবেন

• Load, stress, spike ও soak test আলাদা করা
• Realistic workload এবং success criteria লেখা
• Generator limit ও misleading result চিনতে পারা

সমস্যা দিয়ে শুরু

Launch-এর আগে health route হাজারবার hit করে team ঘোষণা দিল দোকান ready। কিন্তু checkout database transaction ও payment dependency চালায়; health route সেই কাজ করে না। Production-এ traffic বাড়লে connection pool ভরে গেল। Load test-এর মূল্য tool-এর request count নয়; representative scenario, arrival pattern, data এবং measured business outcome-এর উপর নির্ভর করে।

সহজ করে বুঝি

Load test expected traffic-এ behavior দেখে। Stress test capacity boundary ও degradation খোঁজে। Spike test sudden change, soak test দীর্ঘ সময়ে leak ও resource growth দেখে। Concurrent users এবং requests per second এক unit নয়। Response time বাড়লে closed-loop client নিজেই কম request পাঠাতে পারে, ফলে overload কম দৃশ্যমান হয়। Arrival model এবং generator saturation রিপোর্টে লিখুন।

পরিচিত একটি উপমা

সেতুর পরীক্ষা শুধু এক cyclist চালিয়ে হয় না। Expected vehicle mix, sudden traffic এবং দীর্ঘ সময়ের চাপ দেখতে হয়। তবে পরীক্ষা করতে গিয়ে আসল শহরের সব পথ আটকে দেওয়াও উদ্দেশ্য নয়; scope ও stop rule দরকার।

নকশাটি দেখুন

flowchart LR
 P[Workload and data model] --> G[Controlled traffic generator]
 G --> A[Laravel staging service]
 A --> D[(Representative database)]
 A --> S[Sandbox dependencies]
 A --> M[Latency errors saturation]
 M --> J[Compare pass criteria]

Workload product browse, cart এবং checkout-এর অনুপাত নির্ধারণ করে। Generator controlled environment-এ traffic পাঠায়। Database size এবং sandbox dependency বাস্তব constraints যতটা সম্ভব মেলে। Metrics থেকে latency, error, throughput ও resource saturation দেখা হয়। Generator নিজেই CPU-bound হলে application capacity conclusion ভুল হবে। Test শেষে data cleanup এবং side-effect reconciliation করুন।

PHP ও Laravel-এ প্রয়োগ

Laravel Artisan command-এর ছোট sequential smoke probe fragment। HTTP client ব্যবহার করলেও এটি concurrent load generator নয়। Base URL config/testing.php-তে isolated environment, payment sandbox এবং seeded data ধরে নিন। Real stress-এর জন্য dedicated tool ব্যবহার করা যায়; primary application examples PHP/Laravel-ই থাকবে।

use Illuminate\Support\Facades\Http;
$baseUrl = config('testing.target_url');
$results = [];
for ($attempt = 0; $attempt < 5; $attempt++) {
    $started = hrtime(true);
    $response = Http::timeout(5)->get($baseUrl.'/catalog');
    $results[] = [
        'status' => $response->status(),
        'seconds' => (hrtime(true) - $started) / 1e9,
    ];
}

সুবিধা, সীমাবদ্ধতা ও trade-off

Realistic full journey confidence বাড়ায়, তবে setup, cleanup ও safe test data ব্যয়বহুল। Small isolated test bottleneck pinpoint করে কিন্তু end-to-end behavior কম বোঝায়। Warm cache best case হতে পারে; cold cache ও peak tenant test আলাদা করুন। External provider-এর permission ও rate limit মানুন। Production load experiment কেবল explicit scope, monitoring ও abort controlসহ করুন।

সাধারণ ভুল

• Health route-এর throughput-কে checkout capacity বলা।
• Generator saturation যাচাই না করা।
• Sandbox ছাড়া real charge, email বা SMS পাঠানো।

আরও একটু গভীরে

Coordinated omission slow response-এর সময় missed arrivals বাদ দিয়ে latency সুন্দর দেখাতে পারে; arrival scheduling ও histogram interpretation বুঝুন। Queue workload-এ enqueue success নয়, completion latency ও backlog drain time মাপুন। Soak test-এ memory, connection count ও storage growth দেখুন। Pass criteria আগে লিখলে ফল দেখে সুবিধামতো target বদলানোর প্রবণতা কমে।

মনে রাখুন

Load test হলো workload model ও measurable hypothesis; tool count, health ping বা average latency একা capacity প্রমাণ নয়।

নিজে চেষ্টা করুন

Sale-এর জন্য workload mix, target arrival rate, test duration এবং abort condition লিখুন। Checkout completion ও queue drain-এর criteria দিন। Cold cache, sudden spike এবং generator bottleneck আলাদাভাবে কীভাবে পরীক্ষা করবেন বলুন।

নিজের বোঝা যাচাই করুন

1. Load ও stress এক?

Load expected demand যাচাই করে; stress boundary ও failure behavior খোঁজে। উদ্দেশ্য ও stop rule আলাদা।

2. Sequential loop load test?

ছোট smoke timing হতে পারে, meaningful concurrent capacity proof নয়। Generator model স্পষ্ট লিখতে হবে।

3. Enqueue success যথেষ্ট?

না। Worker completion delay, failure ও backlog drain time user outcome নির্ধারণ করে।

4. Average ভালো মানেই pass?

Tail latency, error rate, throughput ও resource saturationও target পূরণ করতে হবে।

5. Test data কেন গুরুত্বপূর্ণ?

Tiny dataset indexes, memory এবং query plan-এর বাস্তব চাপ লুকাতে পারে। Representative size ও safe synthetic data দরকার।

আরও পড়ুন

• Grafana k6 test types
• Laravel HTTP client