Load Test در توسعه اپلیکیشن موبایل — این چیستؘ سناریوها و چگونگی انجام آن

Load Test چیست؟

Load Test (آزمون باری) — فرآیندی است برای بررسی عملکرد سیستم تحت تعداد مورد انتظار درخواست‌ها یا کاربران همزمان. در زمینه توسعه اپلیکیشن موبایل، Load Test هم برای بخش سرور (API، پایگاه داده، کش) و هم برای بخش مشترک (پردازش اطلاع‌رسانی های push، همگام‌سازی داده‌ها) اعمال می‌شود. تفاوت اصلی با آزمون تنش این است که Load Test بار واقعی را مدلسازی می‌کند، نه بار افراطی. بر اساس AWS Well-Architected Framework (2024)، آزمون باری باید با استفاده از پروفیل‌های باری مبتنی بر تحلیل واقعی مصرف انجام شود.

Load Test می‌تواند در سطح درخواست‌های HTTP به API، در سطح اتصالات WebSocket یا در سطح تراکنش‌های پایگاه داده انجام شود. هدف اطمینان از این است که زمان پاسخ هر درخواست از آستانه تعیین‌شده (معمولاً 500–1000 میلی‌ثانیه برای API) تجاوز نکند و ظرفیت انتقال (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های خارجی (خدمات کند شرکت ثالث). Distributed tracing (Jaeger, Zipkin) به محلی‌سازی مشکل در سطح یک خدمت یا درخواست خاص کمک می‌کند.

هدف سوم تعیین نقطه اشباع (saturation point) است. این لحظه‌ای است که افزودن کاربران جدید ظرفیت انتقال را افزایش نمی‌دهد. در اپلیکیشن‌های موبایل، نقطه اشباع معمولاً در 70–80% بارگیری CPU در سرورهای پایگاه داده رخ می‌دهد. Auto-scaling باید قبل از رسیدن به این نقطه فعال شود.

سناریوهای آزمون باری

بار پیکی (Spike Test) — افزایش ناگهانی فعالیت را مدلسازی می‌کند، مانند ارسال صبحگاهی اطلاع‌رسانی‌های push یا شروع یک کمپین تبلیغاتی. بر اساس Grafana k6 (2025)، Spike Test افزایش بار را از 100 به 10000 RPS در 30 ثانیه شبیه‌سازی می‌کند. سیستم باید بدون از دست دادن درخواست‌ها و بدون افزایش زمان پاسخ بیش از 50% مقاومت کند.

بار ثابت (Endurance Test) — بررسی پایداری سیستم در کار طولانی تحت بار. مدت زمان تیپیکی — 1–4 ساعت. Endurance Test نشت حافظه در اپلیکیشن‌های سرور، مشکلات پول اتصالات به پایگاه داده و تنزل عملکرد کش را آشکار می‌سازد. پول اتصالات PostgreSQL در بار طولانی بدون پیکربندی مناسب می‌تواند پس از 2–3 ساعت کار، اتصالات موجود را تمام کند.

بار پله‌ای (Step Load Test) — افزایش تدریجی بار با گام 10–20% هر 2–5 دقیقه. این سناریو به پیدا کردن مرز دقیقی کمک می‌کند که پس از آن سیستم تنزل می‌یابد. InfluxDB و Prometheus در هر گام متریک‌ها را برای ساخت نقشه وابستگی زمان پاسخ به RPS جمع‌آوری می‌کنند.

متریک‌های Load Test

زمان پاسخ

زمان پاسخ (Response Time) — متریک اصلی Load Test است. به میلی‌ثانیه اندازه‌گیری می‌شود و بر اساس پرسنتیل‌ها تحلیل می‌شود: p50 (واسطه)، p95 و p99. Google SRE (2024) آستانه p95 را حداکثر 1000 میلی‌ثانیه برای REST API و حداکثر 200 میلی‌ثانیه برای gRPC توصیه می‌کند. پرسنتیل‌ها از میانگین مهم‌تر هستند زیرا رفتار بدترین درخواست‌ها را نشان می‌دهند که کاربران ابتدا متوجه می‌شوند. Apdex (Application Performance Index) — متریک مرکب که سهم کاربران راضی، متحمل و ناراضی را در نظر می‌گیرد.

ظرفیت انتقال

ظرفیت انتقال (Throughput) — تعداد درخواست‌های موفق در واحد زمان. به RPS (تعداد درخواست در ثانیه) یا TPS (تعداد تراکنش در ثانیه) اندازه‌گیری می‌شود. نقشه ظرفیت انتقال در مختصات “زمان — RPS” باید تا نقطه اشباع خطی باشد. کاهش ناگهانی ظرفیت انتقال هنگام افزایش بار نشانه رسیدن به حد سیستم است. Apache Bench و wrk — ابزارهای ساده CLI برای بررسی سریع ظرفیت انتقال در مرحله توسعه.

درصد خطا

درصد خطا (Error Rate) — نسبت پاسخ‌های با کد وضعیت HTTP 4xx یا 5xx به تعداد کل درخواست‌ها. آستانه مجاز — کمتر از 1%. خطاهای 429 (Too Many Requests) و 503 (Service Unavailable) در بار بالا نشان‌دهنده نیاز به تنظیم محدودیت نرخ (rate limiting) و مقیاس‌بندی خودکار هستند. Rate limiter در طرف API Gateway از بکاند در برابر تجاوز از بار مجاز محافظت می‌کند. Retry policy با exponential backoff به مشتریان کمک می‌کند خطاهای موقتی را به طور صحیح مدیریت کنند.

ابزارهای Load Test

k6 (Grafana)

k6 — ابزار باز منبع پیشرو برای آزمون باری از Grafana. اسکریپت‌ها به JavaScript نوشته می‌شوند، سناریوهای مدولار، آستانه‌ها (thresholds) و اتصال به Prometheus و InfluxDB پشتیبانی می‌شود. k6 هم در CLI و هم در ابر Grafana Cloud k6 قابل اجراست. Grafana Cloud به طور خودکار داشبوردهایی از نتایج Load Test می‌سازد و آن‌ها را با داده‌های تاریخی مقایسه می‌کند. k6 از Protocol Buffers و gRPC از طریق ماژول جداگانه k6/net/grpc پشتیبانی می‌کند.

Apache JMeter

Apache JMeter — ابزار کلاسیک Load Test با رابط گرافیکی. مجموعه گسترده‌ای از پروتکل‌ها را پشتیبانی می‌کند: HTTP، JDBC، JMS، FTP و TCP. JMeter برای سناریوهای پیچیده با انواع مختلف درخواست مناسب‌تر است، اما در مقایسه با k6 به پیکربندی بیشتری نیاز دارد. JMeter Plugins قابلیت آزمایش WebSocket و gRPC را افزایش می‌دهد. برای اجرای توزیع‌شده، JMeter از معماری master-slave با یک کنترلر استفاده می‌کند.

Locust

Locust — ابزاری بر پایه Python که به شما امکان می‌دهد سناریوهای باری را در کد توصیف کنید. Locust برای تیم‌هایی که از Python به عنوان زبان اصلی برای اتوماسیون استفاده می‌کنند مناسب است. به میزان k6 و JMeter، Locust از همان ابتدا اجرای توزیع‌شده را پشتیبانی می‌کند: یک master-node چندین worker-node را هماهنگ می‌کند. اجرای توزیع‌شده امکان ایجاد بار تا 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)
}

نمونه نوشتن Load Test در k6

اسکریپت k6 در بالا ساختار تیپیک یک آزمون باری را نشان می‌دهد. Options نیرخ بار را تعیین می‌کند: ramp-up به مدت 2 دقیقه تا 100 کاربر، سپس 5 دقیقه بار ثابت و دوباره ramp-up تا 200 کاربر. Thresholds معیارهای پاس آزمون را تعیین می‌کنند: p95 زمان درخواست حداکثر 500 ms، درصد خطا کمتر از 1%. اگر آستانه‌ها تجاوز شوند، k6 آزمون را با کد غیر صفر پایان می‌دهد — این امکان ادغام Load Test در CI/CD را فراهم می‌کند.

در توسعه اپلیکیشن موبایل، Load Test بخش سرور به‌ویژه در راه‌اندازی ویژگی‌های جدید که بار اضافی ایجاد می‌کنند مهم است: لایک‌ها، نظرات، پخش زنده. توصیه — آزمون باری را در هر staging قبل از انتشار در تولید انجام دهید. ایجاد یک نیرخ باری پایه در مرحله طراحی API به جلوگیری از مشکلات معماری در مراحل بعدی کمک می‌کند.