موبائل ڈویلپمنٹ میں اسٹریس ٹیسٹ: یہ کیا ہے، اہداف اور کیسے کیا جاتا ہے

Stress Test کیا ہے؟

Stress Test (اسٹریس ٹیسٹ) — حسابی اقدار سے زیادہ حالات میں سسٹم کے کام کرنے کی صلاحیت کا جائزہ لینے کا عمل ہے۔ موبائل ایپلی کیشن کے لیے، اس کا مطلب 1000 کے معمول کے مقابلے میں 10000 بیک وقت پش نوٹیفکیشن ہو سکتا ہے، بیک اینڈ کے لیے — متوقع 5000 کے مقابلے میں 50000 RPS۔ Stress Test کا Load Test سے بنیادی فرق یہ ہے کہ مقصد کارکردگی کی تصدیق نہیں بلکہ ڈیزائن کی گنجائش سے باہر سسٹم کے رویے کا مطالعہ کرنا ہے۔ Netflix Engineering (2024) Stress Test کو “اس مفروضے کی جانچ کہ سسٹم پیش قیاسی طور پر ناکام ہو گا” کے طور پر بیان کرتا ہے۔

اسٹریس ٹیسٹنگ میں دو لازمی مراحل شامل ہیں: ناکامی تک بوجھ اور بحالی کا مشاہدہ۔ بحالی (recovery) — اوورلوڈ ہٹانے کے بعد سسٹم کی معمول کے کام پر واپس آنے کی صلاحیت۔ وہ سسٹم جو دوبارہ شروع کیے بغیر بحال نہیں ہوتا، نازک سمجھا جاتا ہے، چاہے وہ مختصر مدت کا اوورلوڈ برداشت کر لے۔ AWS Well-Architected Framework (2024) کے مطابق، Stress Test کے بعد بحالی کا وقت 5 منٹ سے زیادہ نہیں ہونا چاہیے۔

موبائل کلائنٹس کے لیے Stress Test میں شامل ہے: زبردستی عمل ختم کرنا، نیٹ ورک منقطع کرنا اور RAM ختم ہونے پر کام کی جانچ۔ Android Low Memory Killer RAM کی کمی پر پس منظر کے عمل کو ختم کر سکتا ہے — اسٹریس ٹیسٹ کو تصدیق کرنی چاہیے کہ ایپلی کیشن اس طرح کے خاتمے کے بعد حالت کو درست طریقے سے بحال کرتی ہے۔ Apple UIKit (2024) ایپلی کیشن کی ہر اسکرین پر میموری وارننگ منظرناموں کی جانچ کرنے کی سفارش کرتا ہے۔

اسٹریس ٹیسٹنگ کے اہداف

ناکامی کے نقطہ کا تعین

Stress Test کا پہلا مقصد ناکامی کے نقطہ کا تعین (breaking point) ہے۔ یہ وہ لمحہ ہے جب کارکردگی کے اہم اشاریوں میں سے ایک تنقیدی حد کو عبور کرتا ہے: p95 رسپانس ٹائم 10 سیکنڈ سے زیادہ، HTTP 5XX خرابیوں کا فیصد 5% سے زیادہ، یا تھرو پٹ baseline کے 50% سے نیچے گر جاتا ہے۔ ناکامی کے نقطہ کی ریکارڈنگ ٹیم کو سسٹم کی اسکیلنگ کی حد پہلے سے جاننے دیتی ہے۔ صلاحیت کی منصوبہ بندی Stress Test کے اعداد و شمار پر انحصار کرتی ہے، Load Test پر نہیں، کیونکہ Load Test حدی حالات کی جانچ نہیں کرتا۔

بحالی کے میکانزم کی جانچ

دوسرا مقصد بحالی کے میکانزم کی جانچ ہے۔ بوجھ معمول کی سطح پر کم ہونے کے بعد سسٹم کو معیاری اشاریوں پر واپس آنا چاہیے۔ اگر ڈیٹابیس سے کنکشن پول آزاد نہیں ہوتا یا کیشے باطل نہیں ہوتا، Stress Test اس مسئلے کی نشاندہی کرے گا۔ Circuit breaker (Hystrix, Resilience4j) کو اوورلوڈ پر فعال ہونا چاہیے اور استحکام کے بعد خود بخود کنکشن بحال کرنا چاہیے۔ Health check اینڈ پوائنٹس ٹیسٹ کے دوران ہر سروس کی حالت کی نگرانی میں مدد کرتے ہیں۔

Auto-scaling کی توثیق

تیسرا مقصد auto-scaling کی توثیق ہے۔ اگر بنیادی ڈھانچہ Kubernetes یا AWS Auto Scaling استعمال کرتا ہے، Stress Test چیک کرتا ہے کہ نئے pod یا instances کافی تیزی سے بنائے جا رہے ہیں۔ Google Kubernetes Engine (2024) کے مطابق، HPA (Horizontal Pod Autoscaler) میٹرک کے متحرک ہونے سے نئے pod کی تعیناتی کا وقت 30 سیکنڈ سے زیادہ نہیں ہونا چاہیے۔ HPA کو CPU، میموری اور حسب ضرورت میٹرکس کی بنیاد پر پیمائش کرنی چاہیے۔ Cluster Autoscaler نئے نوڈس شامل کرتا ہے اگر موجودہ نوڈس pod کو جگہ نہیں دے سکتے۔

Stress Test کا طریقہ کار

بتدریج بوجھ میں اضافہ (Ramp-up Stress Test) — سب سے عام منظرنامہ۔ ابتدائی بوجھ متوقع بوجھ کے 50% پر مقرر کیا جاتا ہے، پھر ہر 2 منٹ میں 10% بڑھایا جاتا ہے جب تک سسٹم ناکام نہ ہو جائے۔ یہ منظرنامہ استحکام کی صحیح حد تلاش کرنے دیتا ہے۔ Grafana Cloud k6 (2025) رسپانس ٹائم کا ہموار گراف حاصل کرنے کے لیے 10% سے زیادہ اضافہ نہ کرنے کی سفارش کرتا ہے۔

اچانک بوجھ میں اضافہ (Spike Stress Test) — بوجھ 10–30 سیکنڈ میں 10% سے 500% تک بڑھ جاتا ہے۔ یہ منظرنامہ وائرل مواد کے پھیلاؤ یا DDoS حملے جیسی صورتحال کو ماڈل کرتا ہے۔ Spike Stress Test کارکردگی سے زیادہ سسٹم کی زندہ رہنے کی صلاحیت جانچتا ہے: مکمل طور پر گرنے سے بچنے اور استحکام کے بعد کام پر واپس آنے کی صلاحیت۔ API Gateway کو اچانک اضافے سے بیک اینڈ کے تحفظ کے لیے ریٹ لمیٹنگ ترتیب دینی چاہیے۔

طویل مدتی اوورلوڈ برقرار رکھنا (Sustained Stress Test) — سسٹم 30–60 منٹ تک اوورلوڈ حالت میں رکھا جاتا ہے۔ یہ منظرنامہ وسائل کے رساو کو ظاہر کرتا ہے جو مختصر مدت کے ٹیسٹوں میں نظر نہیں آتے۔ میموری رساو Java/Kotlin ایپلی کیشنز میں 20–40 منٹ کی شدید کارروائی کے دوران جمع ہوتا ہے اور صرف Sustained Stress Test اسے پکڑتا ہے۔

ناکامی کے نقطہ اور بحالی کا تجزیہ

ناکامی کا نقطہ تین معیاروں کے مطابق متعین کیا جاتا ہے: رسپانس ٹائم، خرابیوں کا فیصد اور تھرو پٹ۔ عام طور پر پہلے رسپانس ٹائم کی حد عبور ہوتی ہے — درخواستیں مقررہ حد سے زیادہ وقت لینے لگتی ہیں۔ پھر خرابیوں کا فیصد بڑھتا ہے: سرور درخواستوں پر کارروائی نہیں کر پاتا اور 503 لوٹاتا ہے۔ آخر میں Throughput گرتا ہے — سسٹم کم سے کم بوجھ بھی سنبھال نہیں پاتا۔ ناکامی کے نقطہ کا میٹرک صلاحیت کی منصوبہ بندی کے لیے بوجھ کے پروفائل میں ریکارڈ کیا جاتا ہے۔

بحالی کا تجزیہ تین مراحل پر مشتمل ہے: فوری ردعمل (بوجھ ہٹانے کے بعد پہلے 30 سیکنڈ)، استحکام (1–5 منٹ) اور مکمل بحالی (5–30 منٹ)۔ فوری ردعمل کے مرحلے میں رسپانس ٹائم baseline سے نیچے گرنا چاہیے — سسٹم قطاروں سے آزاد ہو جاتا ہے۔ اگر ایسا نہیں ہوتا، مسئلہ بوجھ میں نہیں بلکہ جمع شدہ حالت میں ہے۔ Graceful degradation — اوورلوڈ میں سسٹم کی جزوی فعالیت برقرار رکھنے کی صلاحیت — فن تعمیر کی پختگی کا کلیدی اشارہ ہے۔

Chaos Engineering جان بوجھ کر خرابیاں ڈال کر Stress Test کی تکمیل کرتا ہے: ڈیٹابیس سرور بند کرنا، نیٹ ورک میں تاخیر، مائیکرو سروس روکنا۔ Chaos Monkey Netflix (2024) سے بے ترتیب طور پر پروڈکشن میں عمل ختم کرتا ہے، سسٹم کی لچک کی جانچ کرتا ہے۔ موبائل ایپلی کیشنز کے لیے Chaos Engineering کا مطلب منظرناموں کی جانچ ہے: نیٹ ورک کی عدم موجودگی، API کی غیر دستیابی، سرور کا خالی جواب۔

Stress Test کے اوزار

ramping-arrival-rate کے ساتھ k6

k6 ramping-arrival-rate کنفیگریشن کے ساتھ `execution` ماڈیول کے ذریعے Stress Test کو سپورٹ کرتا ہے۔ یہ موڈ ہر درخواست کے عملدرآمد کے وقت سے قطع نظر فی سیکنڈ درخواستوں کی تعداد بڑھاتا ہے۔ Load Test کے مقابلے میں، k6 میں Stress Test کے لیے زیادہ جارحانہ thresholds ترتیب اور اچانک ناکامی کی نقل کے لیے gracefull-stop بند کرنے کی ضرورت ہے۔ Grafana Cloud خود بخود رسپانس ٹائم گراف کے موڑ سے ناکامی کے نقطہ کا پتہ لگاتا ہے۔ k6-operator for Kubernetes کلسٹر سے تقسیم شدہ Stress Test چلانے کی اجازت دیتا ہے۔

Ultimate Thread Group کے ساتھ JMeter

JMeter Ultimate Thread Group کے ذریعے Stress Test ترتیب دینے کی اجازت دیتا ہے — ایک پلگ ان جو بوجھ کا پروفائل جدول کی شکل میں متعین کرتا ہے: تھریڈز کی تعداد، گرم ہونے کا وقت، برقرار رکھنے کا وقت، ٹھنڈا ہونے کا وقت۔ Ultimate Thread Group پیچیدہ کثیر مرحلہ منظرناموں کے لیے آسان ہے۔ JMeter Backend Listener ناکامی کے نقطہ کے گراف بنانے کے لیے InfluxDB کو میٹرکس بھیجتا ہے۔ Stress Test کے لیے، JMeter میں کنکشن ٹائم آؤٹ بند کرنے کی سفارش کی جاتی ہے تاکہ اوورلوڈ میں رویے کو زیادہ درست طریقے سے ناپا جا سکے۔

Chaos Engineering کے لیے Gremlin

Gremlin — بنیادی ڈھانچے کے Stress Test کے لیے Chaos Engineering پلیٹ فارم۔ Gremlin نیٹ ورک منقطع کرنے، CPU لوڈ کرنے، ڈسک بھرنے اور Kubernetes کے انفرادی pod پر عمل ختم کرنے کی اجازت دیتا ہے۔ SRE ٹیمیں Gremlin کو k6 کے ساتھ جامع Stress Test کے لیے استعمال کرتی ہیں: k6 بوجھ پیدا کرتا ہے، Gremlin خرابیاں ڈالتا ہے۔ Game Day — Gremlin استعمال کرتے ہوئے باقاعدہ Stress Test سیشن، جن کے نتائج سسٹم کی لچک کے تجزیے کے لیے “caos رپورٹ” میں دستاویز کیے جاتے ہیں۔

k6 پر Stress Test کی مثال

نیچے دیا گیا k6 اسکرپٹ ناکامی تک بتدریج بوجھ میں اضافے کے ساتھ Stress Test کو ظاہر کرتا ہے۔ Ramping-arrival-rate ہر درخواست کے عملدرآمد کے وقت سے قطع نظر فی سیکنڈ درخواستوں کی تعداد بڑھاتا ہے۔ Thresholds جارحانہ تنزلی کی نشاندہی کے لیے ترتیب دیے گئے ہیں: p95 2000 ms سے زیادہ نہ ہو، ایرر ریٹ 5% سے زیادہ نہ ہو۔ حدود عبور ہونے پر k6 خرابی کوڈ کے ساتھ ٹیسٹ ختم کرتا ہے، جو Stress Test کو CI/CD پائپ لائن میں ضم کرنے دیتا ہے۔

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

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

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

اسٹریس ٹیسٹنگ کے بہترین طریقے

Stress Test staging پر شروع کریں — پروڈکشن اسٹریس ٹیسٹنگ کے لیے جدید نگرانی اور رول بیک پلان کی ضرورت ہے۔ Google SRE (2024) 100% الگ تھلگ ماحول میں Stress Test کرنے کی سفارش کرتا ہے جو فن تعمیر اور صلاحیتوں میں پروڈکشن کی نقل کرتا ہے۔ staging پر کامیاب ٹیسٹ کے بعد SRE کی نگرانی میں پروڈکشن پر جایا جا سکتا ہے۔ Feature flag اوورلوڈ پر فعالیت بند کرنے کے لیے — ایک لازمی عنصر۔

CI/CD میں Stress Test خودکار کریں ناکامی کے نقطہ کے رجعت تجزیے کے لیے۔ اگر ایپلی کیشن کے نئے ورژن کا ناکامی کا نقطہ پچھلے سے 20% کم ہے، یہ ایک رجعت ہے جسے ریلیز سے پہلے درست کرنا ضروری ہے۔ Baseline breaking point میٹرکس میں محفوظ کیا جاتا ہے اور خود بخود ہر Stress Test کے نتیجے سے موازنہ کیا جاتا ہے۔ ناکامی کے نقطہ میں 10% کمی پر الرٹ فعال ہوتا ہے۔

ہر Stress Test کو دستاویز کریں: بوجھ کا پروفائل، ناکامی کا نقطہ، بحالی کا رویہ اور دریافت شدہ مسائل کی فہرست۔ Netflix Engineering (2024) “Game Day” چلاتا ہے — باقاعدہ Stress Test سیشن، جن کے نتائج “caos رپورٹ” میں دستاویز کیے جاتے ہیں۔ اسٹریس ٹیسٹ رپورٹ میں “RPS — رسپانس ٹائم” گراف ہونا چاہیے جس میں ناکامی کا نقطہ نشان زد ہو۔