موبائل ڈیویلپمنٹ میں Load Test — یہ کیا ہے، مناظر اور کیسے کیا جاتا ہے

Load Test کیا ہے؟

Load Test اس بات کی تصدیق کے لیے ایک عمل ہے کہ ایک سسٹم متوقع تعداد میں بہ الوقت درخواستوں یا صارفین کے تحت کیسا کام کرتا ہے۔ موبائل ڈیویلپمنٹ کے سیاق میں، Load Test سرور سائڈ (API، ڈیٹابیس، کیش) اور کلائینٹ سائڈ (push اطلاع کے پروسیسنگ، ڈیٹا سنکرونائیزیشن) دونوں پر لاگو ہوتا ہے۔ سٹریس ٹیسٹنگ سے بنیادی فرق یہ ہے کہ Load Test حقیقی، انتہا نہیں، لوڈ کی نقل کرتا ہے۔ AWS Well-Architected Framework (2024) کے مطابق، لوڈ ٹیسٹنگ حقیقی استعمال کے تجزیے پر مبنی لوڈ پروفائل استعمال کرکے کیا جانا چاہیے۔

Load Test API کو HTTP درخواستوں، WebSocket کنیکشنز، یا ڈیٹابیس لیندے کے سطح پر کیا جا سکتا ہے۔ مقصد یہ یقینی بنانا ہے کہ ہر درخواست کا جوابی وقت ایک متعین حد (عام طور پر API کے لیے 500–1000 ms) سے تجاوز نہ کرے، اور تھروپٹ (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 میں پیک لوڈ کے 2 گنا مارج کے ساتھ لوڈ ٹیسٹنگ کی جاتی ہے: اگر 10000 RPS متوقع ہے، تو ٹیسٹ 20000 RPS کی تصدیق کرتا ہے۔ یہ نظریہ اچانک ٹریفک میں اضافے کے دوران استحکام کی ضمانت دیتا ہے۔

دوسرا مقصد آرکیٹیکچر میں رکاوٹوں کی شناخت کرنا ہے۔ موبائل بیک اینڈ میں معمولی رکاوٹیں ہیں: ڈیٹابیس (سست استعلامات)، کیش (غلط باتیل حکمت عملی)، اور بیرونی API (سست تیسری جنب کی خدمات)۔ منتشر ٹریسنگ (Jaeger, Zipkin) ایک مخصوص سروس یا درخواست کی سطح پر مسئلہ کو مقامی کرنے میں مدد کرتا ہے۔

تیسرا مقصد اطمینان کے نقطے کا تعین کرنا ہے۔ یہ وہ لمحہ ہے جب نئے صارفین کو شامل کرنا تھروپٹ میں مزید اضافہ نہیں کرتا۔ موبائل ایپلیکیشنوں میں، اطمینان کا نقطہ عام طور پر ڈیٹابیس سرور پر 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 کے میٹرکس

جوابی وقت

جوابی وقت Load Test کا بنیادی میٹرک ہے۔ ملی سیکنڈ میں ناپا جاتا ہے اور فیصدوں کے اعتماد سے تجزیہ کیا جاتا ہے: p50 (وسطی)، p95 اور p99۔ Google SRE (2024) REST API کے لیے 1000 ms اور gRPC کے لیے 200 ms سے زیادہ نہیں p95 حد کی سفارش کرتا ہے۔ فیصدے اوسط سے زیادہ اہم ہیں کیونکہ وہ سب سے بری درخواستوں کے رویے کو ظاہر کرتے ہیں، جسے صارف سب سے پہلے محسوس کرتے ہیں۔ Apdex (ایپلیکیشن کارکردگی انڈیکس) ایک مرکب میٹرک ہے جو مطمئن، برداشت کرنے والے، اور مایوس صارفین کے تناسب پر غور کرتا ہے۔

تھروپٹ

تھروپٹ (Throughput) — وقت کی فی اکائی کامیاب درخواستوں کی تعداد۔ RPS (فی سیکنڈ درخواستیں) یا TPS (فی سیکنڈ لیندے) میں ناپا جاتا ہے۔ میتر “وقت — RPS” میں Throughput کا گراف اطمینان کے نقطے تک لینیئر ہونا چاہیے۔ بڑرے لوڈ کے ساتھ Throughput میں تیز گراوٹ سسٹم کی حد تک پہونچنے کی نشانی ہے۔ Apache Bench اور wrk ترقی کے دوران تھروپٹ کی فوری جانچ کے لیے سادہ CLI آلات ہیں۔

غلطی کی شرح

غلطی کی شرح (Error Rate) — کل درخواستوں میں HTTP اسٹیٹس 4xx یا 5xx کے جوابوں کا تناسب۔ قابل قبول حد 1% سے کم ہے۔ زیادہ لوڈ کے تحت 429 (Too Many Requests) اور 503 (Service Unavailable) کی غلطیاں ریٹ لیمٹنگ اور خود کار سکیلنگ کی ترتیب کی ضرورت کو ظاہر کرتی ہیں۔ API Gateway پر ریٹ لیمٹر بیک اینڈ کو مجاز لوڈ سے تجاوز کرنے سے بچاتا ہے۔ اکسپونینشیل بیک آف کے ساتھ دوبارہ کوشش کی پالیسی کلائینٹ کو عارضی غلطیوں کو صحیح طور پر سنبھالنے میں مدد کرتی ہے۔

Load Test کے لیے آلات

k6 (Grafana)

k6 — Grafana کا پیشرو اوپن سورس لوڈ ٹیسٹنگ ٹول۔ اسکرپٹس JavaScript میں لکھے جاتے ہیں، ماڈیولر مناظر، حدود (thresholds)، اور 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 ms سے زیادہ نہیں، غلطی کی شرح 1% سے کم۔ اگر حدود سے تجاوز کیا جاتا ہے، k6 غیر صفر کوڈ کے ساتھ باہر نکلتا ہے — یہ Load Test کو CI/CD میں ضم کرنے کی اجازت دیتا ہے۔

موبائل ڈیویلپمنٹ میں، سرور سائڈ کا Load Test اس وقت خاص طور پر اہم ہوتا ہے جب ایسی نئی خصوصیات لانچ کی جاتی ہیں جو اضافی لوڈ پیدا کرتی ہیں: پسندیدگیاں، تبصرے، سٹریمنگ۔ سفارش — پروڈکشن میں تعینات سے پہلے ہر staging پر Load Test کریں۔ API ڈزائن کے مرحلے کے دوران ایک بیس لائن لوڈ پروفائل بنانے سے بعد کے مراحل میں آرکیٹیکچرل مسائل سے بچنے میں مدد ملتی ہے۔