মোবাইল ডেভেলপমেন্টে Load Test — এটি কী, পরিদৃশ্য এবং কিভাবে করা হয়

Load Test কী?

Load Test হল যাচাই করার একটি প্রক্রিয়া যে একটি সিস্টেম অপেক্ষিত সংখ্যক যুগপত্ত অনুরোধ বা ব্যবহারকারীর অধীনে কিভাবে কাজ করে তা নির্ধারণ করে। মোবাইল ডেভেলপমেন্টের প্রাসঙ্গিকে, Load Test উভয় সার্ভার-সাইড (API, ডেটাবেস, ক্যাচ) এবং ক্লাইন্ট-সাইড (push বিজ্ঞপ্তি প্রক্রিয়া, ডেটা সিংক্রোনাইজেশন) উভয়ক্ষেত্রে প্রয়োগ করা হয়। স্ট্রেস টেস্টিং থেকে মূল পার্থক্য হল Load Test বাস্তব, চরম নয়, লোড অনুকরণ করে। AWS Well-Architected Framework (2024) অনুযায়ী, লোড টেস্টিং বাস্তব ব্যবহার বিশ্লেষণের উপর ভিত্তি করে লোড প্রোফাইল ব্যবহার করে পরিচালিত হওয়া উচিত।

Load Test HTTP অনুরোধের স্তরে, WebSocket সংযোগে বা ডেটাবেস লেনদেনের স্তরে পরিচালিত হতে পারে। লক্ষ্য হল নিশ্চিত করা যে প্রতিটি অনুরোধের প্রতিক্রিয়া সময় একটি নির্দিষ্ট সীমা (সাধারণত APIর জন্য 500–1000 মিলিসেকেন্ড) অতিক্রম না করে, এবং থ্রুপুট (RPS — প্রতি সেকেন্ডে অনুরোধ) আবশ্যকতা পূরণ করে। Google Cloud Armor (2024) পরিসংখ্যানের উপর ভিত্তি করে সীমা মান নির্ধারণ করে: গুরুত্বপূর্ণ এন্ডপয়িন্টের জন্য p95 প্রতিক্রিয়া সময় 2 সেকেন্ডের বেশি হওয়া উচিত নয়।

একটি মোবাইল ব্যাকএন্ডের লোড টেস্টিংয়ে বিশিষ্ট পরিদৃশ্যের সিমুলেশন অন্তর্ভুক্ত রয়েছে: রেজিস্ট্রেশন, প্রমাণীকরণ, ফীড লোডিং, ফর্ম জমা দেওয়া। পরিদৃশ্য HAR ফাইল (HTTP Archive) আকারে রেকর্ড করা হয় এবং লোড টেস্টিং টুল দ্বারা পুনরায় চালানো হয়। k6 ডকুমেন্টেশন (2025) অনুযায়ী, HAR রূপান্তর Load Test প্রস্তুতির সময় 60% হ্রাস করতে পারে।

লোড টেস্টিংয়ের লক্ষ্য

Load Testয়ের প্রথম লক্ষ্য হল সিস্টেমের থ্রুপুট নিশ্চিত করা। যদি সপেসিফিকেশনের জন্য 1000 RPS সামাল দেওয়ার প্রয়োজন হয়, তবে লোড টেস্টকে 20% বাফার সাথে এটি নিশ্চিত করতে হবে। Netflix Tech Blog (2024) অনুযায়ী, Netflix এ লোড টেস্টিং পিক লোড থেকে 2x বাফার সাথে পরিচালিত হয়: যদি 10000 RPS অপেক্ষিত, তবে পরীক্ষা 20000 RPS যাচাই করে। এই পদ্ধতি হঠাৎ ট্রাফিক বৃদ্ধির সময় স্থিরতা নিশ্চিত করে।

দ্বিতীয় লক্ষ্য হল আর্কিটেক্চারে প্রতিবন্ধক (bottlenecks) চিহ্নিত করা। মোবাইল ব্যাকএন্ডে বিশিষ্ট প্রতিবন্ধক হল: ডেটাবেস (ধীর ক্যারি), ক্যাচ (ভুল অমান্য কৌশল), এবং বাহ্যিক API (ধীর তৃতীয় পক্ষের সেবা)। বিতরণ ট্রেসিং (Jaeger, Zipkin) একটি নির্দিষ্ট সেবা বা অনুরোধের স্তরে সমস্যাটি চিহ্নিত করতে সাহায্য করে।

তৃতীয় লক্ষ্য হল পরিপূর্ণতা বিন্দু (saturation point) নির্ধারণ করা। এটি হল সেই মুহূর্ত যখন নতুন ব্যবহারকারী যোগ করা আর থ্রুপুট বাড়ায় না। মোবাইল অ্যাপ্লিকেশনে, পরিপূর্ণতা বিন্দু প্রায়ই ডেটাবেস সার্ভারে 70–80% CPU লোডে ঘটে। অটো-স্কেলিং এই বিন্দুতে পৌছার আগে সক্রিয় হওয়া উচিত।

লোড টেস্টিং পরিদৃশ্য

স্পাইক টেস্ট (Spike Test) — কার্যকলাপে হঠাৎ বৃদ্ধির অনুকরণ করে, যেমন সকালের push বিজ্ঞপ্তি ব্যাচ বা বিজ্ঞাপন কাম্পেন শুরু। Grafana k6 (2025) অনুযায়ী, Spike Test 30 সেকেন্ডে লোড 100 থেকে 10000 RPS এ বৃদ্ধির অনুকরণ করে। সিস্টেমকে অনুরোধ না হারিয়ে এবং প্রতিক্রিয়া সময় 50% এর বেশি না বাড়িয়ে এটি সামাল করতে হবে।

এন্ডুরান্স টেস্ট (Endurance Test) — দীর্ঘকালীন লোডের অধীনে সিস্টেমের স্থিরতা যাচাই করে। বিশিষ্ট মিয়াদ 1–4 ঘন্টা। Endurance Test সার্ভার অ্যাপ্লিকেশনে মেমোরি লিক, ডেটাবেস কনেক্শন পুল সমস্যা এবং ক্যাচ পরিদর্শন অবনতি রূপেণ চিহ্নিত করে। PostgreSQL কনেক্শন পুল উপযুক্ত কনফিগরেশন ছাড়া দীর্ঘ লোডের অধীনে 2–3 ঘন্টার মধ্যে উপলব্ধ সংযোগ নিশ্শেষ করতে পারে।

স্টেপ লোড টেস্ট (Step Load Test) — প্রতি 2–5 মিনিটে 10–20% পদক্ষেপে ক্রমশ লোড বৃদ্ধি। এই পরিদৃশ্য সহ সীমানা খুঁজে পেতে সাহায্য করে যার পরে সিস্টেম অবনতি প্রাপ্ত করে। InfluxDB এবং Prometheus প্রতিটি পদক্ষেপে মেট্রিকস সংগ্রহ করে প্রতিক্রিয়া সময় বামাম RPS গ্রাফ তৈরি করে।

Load Test মেট্রিকস

প্রতিক্রিয়া সময়

প্রতিক্রিয়া সময় (Response Time) Load Testয়ের প্রাথমিক মেট্রিক। মিলিসেকেন্ডে পরিমাপ করা হয় এবং পরিসংখ্যান দ্বারা বিশ্লেষণ করা হয়: p50 (মধ্যমা), p95 এবং p99। Google SRE (2024) REST APIর জন্য 1000 মিলিসেকেন্ডের বেশি নয় এবং gRPCর জন্য 200 মিলিসেকেন্ডের বেশি নয় p95 সীমা সুপারিশ করে। পরিসংখ্যান গড় অপেক্ষা গুরুত্বপূর্ণ কারণ তারা সবচেয়ে খারাপ অনুরোধের আচরণ দেখায়, যা ব্যবহারকারীরা সবচেয়ে আগে লক্ষ করে। Apdex (অ্যাপ্লিকেশন পরিদর্শন সূচক) একটি মিশ্রিত মেট্রিক যা সন্তুষ্ট, সহনশীল এবং হাতাশ ব্যবহারকারীদের অনুপাত বিবেচনা করে।

থ্রুপুট

থ্রুপুট (Throughput) — সময়ের একক প্রতি সফল অনুরোধের সংখ্যা। RPS (প্রতি সেকেন্ডে অনুরোধ) বা TPS (প্রতি সেকেন্ডে লেনদেন) এ পরিমাপ করা হয়। নির্দেশাঙ্ক “সময় — RPS” এ Throughput গ্রাফটি পরিপূর্ণতা বিন্দু পর্যন্ত রৈখিক হওয়া উচিত। বৃদ্ধির লোডের সাথে Throughput এ ধারাল পতন হল সিস্টেমের সীমায় পৌছার লক্ষণ। Apache Bench এবং wrk হল উন্নয়নের সময় দ্রুত Throughput যাচাইর জন্য সরল CLI টুল।

ত্রুটির হার

ত্রুটির হার (Error Rate) — মোট অনুরোধের মধ্যে HTTP স্থিতি 4xx বা 5xx সহ প্রতিক্রিয়ার অনুপাত। গ্রহণযোগ্য সীমা 1% এর কম। বেশি লোডের অধীনে ত্রুটি 429 (Too Many Requests) এবং 503 (Service Unavailable) রেট লিমিটিং এবং অটো-স্কেলিং কনফিগরেশনের প্রয়োজনীয়তা নির্দেশ করে। API Gateway এর রেট লিমিটর ব্যাকএন্ডকে অনুমত লোড অতিক্রম থেকে রক্ষা করে। এক্সপোনেন্শিয়াল ব্যাক঑ফ সহ রিট্রি নিতি ক্লাইন্টদের অস্থায়ী ত্রুটি সঠিকভাবে পরিচালনায় সাহায্য করে।

Load Testয়ের জন্য টুলস

k6 (Grafana)

k6 — Grafana এর অগ্রগণি ওপেন সোর্স লোড টেস্টিং টুল। স্ক্রিপ্ট JavaScript এ লেখা হয়, মডিউলার পরিদৃশ্য, থ্রেশোল্ডস এবং Prometheus এবং InfluxDB এর সাথে সংিন্দ্রীকরণ সমর্থন করে। k6 CLI এবং Grafana Cloud k6 উভয় পরিবেশে চালানো যায়। Grafana Cloud Load Test ফলাফল থেকে স্বচালিতভাবে ড্যাশবোর্ড তৈরি করে এবং অতীতের তথ্যের সাথে তুলনা করে। k6 একটি পৃথক k6/net/grpc মডিউলের মাধ্যমে Protocol Buffers এবং gRPC সমর্থন করে।

Apache JMeter

Apache JMeter — গ্রাফিক্যাল ইন্টারফেস সহ একটি ক্লাসিক্যাল Load Test টুল। HTTP, JDBC, JMS, FTP এবং TCP সহ বিস্তৃত প্রোটোকল সমর্থন করে। JMeter অনেক প্রকারের অনুরোধের সাথে জটিল পরিদৃশ্যের জন্য উপযুক্ত কিন্তু k6 এর তুলনায় অধিক ম্যানুয়াল কনফিগরেশন প্রয়োজন। JMeter প্লাগইনস WebSocket এবং gRPC পরীক্ষার জন্য কার্যক্ষমতা বাড়ায়। বিতরিত চালানোর জন্য, JMeter একটি নিয়ন্ত্রক সহ মাস্টার-স্লেভ আর্কিটেক্চার ব্যবহার করে।

Locust

Locust — একটি Python-ভিত্তিক টুল যা কোডে লোড পরিদৃশ্য বর্ণনা করার অনুমতি দেয়। Locust সেই টিমগুলির জন্য সুবিধাজনক যারা তাদের প্রধান অটোমেশন ভাষা হিসাবে Python ব্যবহার করে। k6 এবং JMeter এর বিপরীতে, Locust বাক্স থেকে বিতরিত চালানো সমর্থন করে: একটি মাস্টার নোড একাধিক ওয়ার্কার নোড সমন্বয় করে। বিতরিত চালানো একাধিক মশিন থেকে 100000 RPS পর্যন্ত লোড উত্পাদনের অনুমতি দেয়। Locust কাস্টম এক্সটেনশনের মাধ্যমে WebSocket পরীক্ষাও সমর্থন করে।

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

k6 এ Load Test লেখার উদাহরণ

ঊপর দেখানো k6 স্ক্রিপ্টটি একটি বিশিষ্ট লোড টেস্ট গঠন প্রদর্শন করে। Options লোড প্রোফাইল সংজ্ঞায়িত করে: 2 মিনিটে রেম্প-আপ করে 100 ব্যবহারকারীতে, তারপর 5 মিনিট নিরন্তর লোড, এবং আবার রেম্প-আপ করে 200 ব্যবহারকারীতে। থ্রেশোল্ডস পরীক্ষা উত্তীর্ণের মানদণ্ড সংজ্ঞায়িত করে: p95 অনুরোধ সময় 500 মিলিসেকেন্ডের বেশি নয়, ত্রুটির হার 1% এর কম। যদি থ্রেশোল্ডস অতিক্রম করা হয়, k6 অ-শূন্য কোডে প্রস্থান করে — এটি Load Test কে CI/CD এ সংিন্দ্রীকৃত করার অনুমতি দেয়।

মোবাইল ডেভেলপমেন্টে, সর্ভার-সাইডের Load Test বিশেষ করে গুরুত্বপূর্ণ যখন নতুন বৈশিষ্ট্য চালু করা হয় যা অতিরিক্ত লোড তৈরি করে: লাইক, মন্তব্য, স্ট্রিমিং। সুপারিশ — প্রোডাক্শনে ডিপ্লওয়ের সময় আগে প্রতিটি staging এ Load Test পরিচালনা করুন। API ডিজাইন পর্যায়ে একটি বেসলাইন লোড প্রোফাইল তৈরি করা পরবর্তী পর্যায়ে আর্কিটেক্চারাল সমস্যা এড়াতে সাহায্য করে।