Mobil tətbiq inkişafında Load Test — bu nədir, ssenarilər və necə aparılır

Load Test nədir?

Load Test (yük testi) — sistemin gözlənılən sayda eyni vaxtlı sorğu və ya istifadəçi altında necə işlədiyini yoxlama prosesidir. Mobil tətbiq inkişafı kontekstində Load Test həm server hissəsinə (API, verilənlər bazası, keş), həm də müştəri hissəsinə (push bildirişlərinin işlənməsi, verilənlərin sinxronizasiyası) tətbiq edilir. Stress testindən əsas fərq ondadır ki, Load Test real, ekstremal deyil, yükü modelləşdirir. AWS Well-Architected Framework (2024) məlumatlarına görə, yük testi real istifadə analitikasına əsaslanan yük profillərindən istifadə edərək aparılmalıdır.

Load Test API-ə HTTP sorğuları səviyyəsində, WebSocket qoşulmaları səviyyəsində və ya verilənlər bazası əməliyyatları səviyyəsində aparıla bilər. Məqsəd — hər sorğun cavab müddətinin müəyyən edilmiş həddi (adətən API üçün 500–1000 ms) aşmadığına və ötürücülük qabiliyyətinin (RPS — saniyədə sorğu) tələblərə uyğun olduğuna əmin olmaqdır. Google Cloud Armor (2024) persentillər əsasında hədd dəyərlərini müəyyən edir: kritik endpointlər üçün cavab müddətinin p95-i 2 saniyədən çox olmamalıdır.

Mobil backendin yük testi tipik ssenarilərin simulyasiyasını əhatə edir: qeydiyyat, avtorizasiya, lentin yüklənməsi, formanın göndərilməsi. Ssenarilər HAR (HTTP Archive) faylları şəklində qeyd olunur və yük testi aləti tərəfindən təkrarlanır. k6 sənədlərinə (2025) görə, HAR konvertasiyası Load Test-in hazırlanma vaxtını 60% azaltmağa imkan verir.

Yük testinin məqsədləri

Load Test-in birinci məqsədi sistemin ötürücülük qabiliyyətinin təsdiqlənməsidir. Əgər spesifikasiya 1000 RPS-in işlənməsini tələb edirsə, yük testi bunu 20% ehtiyatla təsdiqləməlidir. Netflix Tech Blog (2024) məlumatlarına görə, Netflix-də yük testi pik yükdən 2x ehtiyatla aparılır: əgər 10000 RPS gözlənirsə, test 20000 RPS yoxlayır. Bu yanaşma ani trafik artımlarında sabitliyi təmin edir.

Ikinci məqsəd arxitekturada dar boğazların aşkarlanmasıdır. Mobil backendlərdə tipik dar boğazlar — verilənlər bazası (yavaş sorğular), keş (yanlış etibarsızlaşdırma strategiyası) və xarici API-lər (yavaş üçüncü tərəf xidmətləridir). Distributed tracing (Jaeger, Zipkin) problemi konkret xidmət və ya sorğu səviyyəsində lokallaşdırmağa kömək edir.

Üçüncü məqsəd doyma nöqtəsinin müəyyən edilməsidir (saturation point). Bu, yeni istifadəçilərin əlavə edilməsinin ötürücülük qabiliyyətini artırmağı dayandırdığı andır. Mobil tətbiqlərdə doyma nöqtəsi tez-tez verilənlər bazası serverlərində CPU-nun 70–80% yüklənməsində baş verir. Auto-scaling bu nöqtəyə çatmamış işə düşməlidir.

Yük testi ssenariləri

Pik yük (Spike Test) — kəskin aktivlik artımını modelləşdirir, məsələn səhər push bildirişlərinin göndərilməsi və ya reklam kampaniyasının başladılması. Grafana k6 (2025) məlumatlarına görə, Spike Test 30 saniyə ərzində yükü 100-dən 10000 RPS-ə qədər artırır. Sistem sorğu itkisi və cavab müddətinin 50%-dən çox artması olmadan öhdəsindən gəlməlidir.

Sabit yük (Endurance Test) — yük altında uzun müddətli iş zamanı sistemin sabitliyinin yoxlanılması. Tipik müddət — 1–4 saat. Endurance Test server tətbiqlərində yaddaş sızıntılarını, verilənlər bazasına qoşulma hovuzu ilə bağlı problemləri və keş performansının deqradasiyasını aşkarlayır. Düzgün konfiqurasiya olmadan PostgreSQL qoşulma hovuzu 2–3 saat işdən sonra mövcud qoşulmaları tükədə bilər.

Pilləli yük (Step Load Test) — hər 2–5 dəqiqədən bir 10–20% addımla yükün tədricən artırılması. Bu ssenari sistemin deqradasiyaya uğradığı dəqiq həddi tapmağa kömək edir. InfluxDB və Prometheus cavab müddətinin RPS-dən asılılıq qrafikini qurmaq üçün hər addımda metrikalar toplayır.

Load Test metrikaları

Cavab müddəti

Cavab müddəti (Response Time) — Load Test-in əsas metrikası. Millisaniyələrlə ölçülür və persentillər üzrə təhlil edilir: p50 (median), p95 və p99. Google SRE (2024) REST API üçün p95 həddini 1000 ms-dən, gRPC üçün isə 200 ms-dən çox olmamağı tövsiyə edir. Persentillər orta göstəricidən daha vacibdir, çünki istifadəçilərin ilk növbədə gördüyü ən pis sorğuların davranışını göstərir. Apdex (Application Performance Index) — məmnun, dözən və məyus istifadəçilərin paylarını nəzərə alan mürəkkəb metrikadır.

Ötürücülük qabiliyyəti

Ötürücülük qabiliyyəti (Throughput) — vaxt vahidi ərzində uğurlu sorğuların sayı. RPS (saniyədə sorğu) və ya TPS (saniyədə əməliyyat) ilə ölçülür. Vaxt — RPS koordinatlarında ötürücülük qrafiki doyma nöqtəsinə qədər xətti olmalıdır. Yük artırıldıqda ötürücülük qabiliyyətinin kəskin düşməsi sistem həddinə çatıldığının əlamətidir. Apache Bench və wrk — inkişaf mərhələsində ötürücülük qabiliyyətini sürətli yoxlamaq üçün sadə CLI alətləridir.

Xəta faizi

Xəta faizi (Error Rate) — ümumi sorğu sayından HTTP 4xx və ya 5xx statuslu cavabların payı. Yol verilən hədd — 1%-dən az. Yüksək yükdə 429 (Too Many Requests) və 503 (Service Unavailable) xətaları rate limiting və auto-scaling konfiqurasiyasına ehtiyac olduğunu göstərir. API Gateway tərəfində rate limiter backend-i icazə verilən yükü aşmaqdan qoruyur. Retry policy exponential backoff ilə müştərilərə müvəqqəti xətaları düzgün idarə etməyə kömək edir.

Load Test üçün alətlər

k6 (Grafana)

k6 — Grafana-dan yük testi üçün aparıcı Open Source aləti. Skriptlər JavaScript ilə yazılır, modul ssenarilər, həddlər (thresholds) və Prometheus və InfluxDB ilə inteqrasiya dəstəklənir. k6 həm CLI-də, həm də Grafana Cloud k6 buludunda işlədilə bilər. Grafana Cloud Load Test nəticlərinə əsasən avtomatik panel qurur və onları tarixi məlumatlarla müqayisə edir. k6 ayrıca k6/net/grpc modulu vasitəsilə Protocol Buffers və gRPC-ni dəstəkləyir.

Apache JMeter

Apache JMeter — qrafik interfeysi olan klassik Load Test aləti. Geniş protokol çeşidini dəstəkləyir: HTTP, JDBC, JMS, FTP və TCP. JMeter müxtəlif tipli sorğuları olan mürəkkəb ssenarilər üçün daha uyğundur, lakin k6 ilə müqayisədə daha çox əl ilə konfiqurasiya tələb edir. JMeter Plugins WebSocket və gRPC testi üçün funksionallığı genişləndirir. Paylanmış işə salma üçün JMeter bir nəzarətçi ilə master-slave arxitekturasından istifadə edir.

Locust

Locust — Python aləti olub, yük ssenarilərini kodda təsvir etməyə imkan verir. Locust Python-u əsas avtomatlaşdırma dili kimi istifadə edən komandalar üçün əlverişlidir. k6 və JMeter-dən fərqli olaraq, Locust qutudan çıxarılan kimi paylanmış işə salmanı dəstəkləyir: bir master-node bir neçə worker-nodeni koordinasiya edir. Paylanmış işə salma bir neçə maşından 100000 RPS-ə qədər yük yaratmağa imkan verir. Locust həmçinin xüsusi genişləndirmələr vasitəsilə WebSocket testini dəstəkləyir.

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-da Load Test yazma nümunəsi

Yuxarıda göstərilən k6 skripti tipik yük testi strukturunu nümayiş etdirir. Options yük profilini müəyyənləşdirir: 100 istifadəçiyə qədər 2 dəqiqə ramp-up, sonra 5 dəqiqə sabit yük və yenidən 200 istifadəçiyə qədər ramp-up. Thresholds testin keçmə meyarlarını təyin edir: sorğu vaxtının p95-i 500 ms-dən çox deyil, xəta faizi 1%-dən az. Həddlər aşılarsa, k6 testi sıfırdan fərqli kodla bitirir — bu, Load Test-in CI/CD-yə qoşulmasına imkan verir.

Mobil tətbiq inkişafında server hissəsinin Load Testi əlavə yük yaradan yeni funksiyaların işə salınması zamanı xüsusilə vacibdir: bəyənmələr, şərhlər, striminq. Tövsiyə — istehsalata çıxmazdan əvvəl hər staging-də Load Test aparmaq. API-nin layihələndirilməsi mərhələsində əsas yük profilinin yaradılması sonrakı mərhələlərdə arxitektura problemlərinin qarşısını almağa kömək edir.