Mobil ishlanmada Load Test — bu nima, stsenariylar va qanday o'tkaziladi

Load Test nima?

Load Test (yuk testi) — bu tizimning kutilayotgan bir vaqtli so'rovlar yoki foydalanuvchilar soni ostida qanday ishlashini tekshirish jarayoni. Mobil ilova ishlanmasi kontekstida Load Test server qismiga (API, ma'lumotlar bazasi, kesh) ham, mijoz qismiga (push bildirishnomalarini qayta ishlash, ma'lumotlarni sinxronlashtirish) ham qo'llaniladi. Stress testidan asosiy farq shundaki, Load Test real, ekstremal emas, yukni modellashtiradi. AWS Well-Architected Framework (2024) ma'lumotlariga ko'ra, yuk testi real foydalanish analitikasiga asoslangan yuk profillaridan foydalangan holda o'tkazilishi kerak.

Load Test API ga HTTP so'rovlari darajasida, WebSocket ulanishlari darajasida yoki ma'lumotlar bazasi tranzaksiyalari darajasida o'tkazilishi mumkin. Maqsad — har bir so'rovning javob vaqti belgilangan chegaradan (odatda API uchun 500–1000 ms) oshmasligiga va o'tkazuvchanlik (RPS — sekundiga so'rovlar soni) talablarga mos kelishiga ishonch hosil qilishdir. Google Cloud Armor (2024) persentillar asosida chegara qiymatlarini belgilaydi: kritik endpointlar uchun javob vaqtining p95 i 2 sekunddan oshmasligi kerak.

Mobil backendning yuk testi odatiy stsenariylarning simulyatsiyasini o'z ichiga oladi: ro'yxatdan o'tish, avtorizatsiya, lentani yuklash, formani yuborish. Stsenariylar HAR (HTTP Archive) fayllari shaklida yozib olinadi va yuk testi vositasi tomonidan takrorlanadi. k6 hujjatlariga (2025) ko'ra, HAR konvertatsiyasi Load Testni tayyorlash vaqtini 60% ga qisqartirish imkonini beradi.

Yuk testining maqsadlari

Load Testning birinchi maqsadi tizimning o'tkazuvchanlik qobiliyatini tasdiqlash dir. Agar spetsifikatsiya 1000 RPS ni qayta ishlashni talab qilsa, yuk testi buni 20% zaxira bilan tasdiqlashi kerak. Netflix Tech Blog (2004) ma'lumotlariga ko'ra, Netflix da yuk testi cho'qqi yukdan 2x zaxira bilan o'tkaziladi: agar 10000 RPS kutilsa, test 20000 RPS ni tekshiradi. Bu yondashuv to'satdan trafik oshishida barqarorlikni kafolatlaydi.

Ikkinchi maqsad arxitekturada tor joylarni aniqlash dir. Mobil backendlardagi odatiy tor joylar — ma'lumotlar bazasi (sekin so'rovlar), kesh (noto'g'ri bekor qilish strategiyasi) va tashqi API lar (sekin uchinchi tomon xizmatlari). Distributed tracing (Jaeger, Zipkin) muammoni muayyan xizmat yoki so'rov darajasida lokalizatsiya qilishga yordam beradi.

Uchinchi maqsad to'yinish nuqtasini aniqlash dir. Bu yangi foydalanuvchilarni qo'shish o'tkazuvchanlikni oshirishni to'xtatadigan moment. Mobil ilovalarda to'yinish nuqtasi ko'pincha ma'lumotlar bazasi serverlarida CPU 70–80% yuklanganda yuz beradi. Auto-scaling bu nuqtaga yetmasdan ishga tushishi kerak.

Yuk testi stsenariylari

Cho'qqili yuk (Spike Test) — keskin faollik oshishini modellashtiradi, masalan ertalabgi push bildirishnomalarini yuborish yoki reklama kampaniyasini boshlash. Grafana k6 (2025) ma'lumotlariga ko'ra, Spike Test 30 sekund ichida yukni 100 dan 10000 RPS gacha oshiradi. Tizim so'rovlarni yo'qotmasdan va javob vaqtini 50% dan ko'p oshirmasdan bardosh berishi kerak.

Doimiy yuk (Endurance Test) — yuk ostida uzoq muddatli ish paytida tizim barqarorligini tekshirish. Odatdagi davomiylik — 1–4 soat. Endurance Test server ilovalarida xotira oqishini, ma'lumotlar bazasiga ulanish hovuzi bilan bog'liq muammolarni va kesh unumdorligining pasayishini aniqlaydi. Ulanish hovuzi PostgreSQL noto'g'ri konfiguratsiyada uzoq muddatli yuk ostida 2–3 soat ishlagandan so'ng mavjud ulanishlarni tugatishi mumkin.

Pog'onali yuk (Step Load Test) — har 2–5 daqiqada 10–20% qadam bilan yukni asta-sekin oshirish. Bu stsenariy tizim degradatsiyaga uchraydigan aniq chegarani topishga yordam beradi. InfluxDB va Prometheus javob vaqtining RPS ga bog'liqlik grafigini qurish uchun har bir qadamda metrikalarni to'playdi.

Load Test metrikalari

Javob vaqti

Javob vaqti (Response Time) — Load Testning asosiy metrikasi. Millisekundlarda o'lchanadi va persentillar bo'yicha tahlil qilinadi: p50 (median), p95 va p99. Google SRE (2024) REST API uchun p95 chegarasini 1000 ms dan, gRPC uchun esa 200 ms dan oshmaslikni tavsiya qiladi. Persentillar o'rtacha ko'rsatkichdan muhimroqdir, chunki ular foydalanuvchilar birinchi navbatda sezadigan eng yomon so'rovlarning xatti-harakatini ko'rsatadi. Apdex (Application Performance Index) — mamnun, toqatli va hafsalasi pir bo'lgan foydalanuvchilarning ulushlarini hisobga oladigan murakkab metrika.

O'tkazuvchanlik

O'tkazuvchanlik (Throughput) — vaqt birligidagi muvaffaqiyatli so'rovlar soni. RPS (sekundiga so'rovlar) yoki TPS (sekundiga tranzaksiyalar) bilan o'lchanadi. “Vaqt — RPS” koordinatalarida o'tkazuvchanlik grafigi to'yinish nuqtasigacha chiziqli bo'lishi kerak. Yuk oshirilganda o'tkazuvchanlikning keskin pasayishi tizim chegarasiga erishilganligining belgisidir. Apache Bench va wrk — ishlanma bosqichida o'tkazuvchanlikni tez tekshirish uchun oddiy CLI vositalari.

Xato foizi

Xato foizi (Error Rate) — umumiy so'rovlar sonidan HTTP 4xx yoki 5xx statusli javoblarning ulushi. Ruxsat etilgan chegara — 1% dan kam. Yuqori yukda 429 (Too Many Requests) va 503 (Service Unavailable) xatolari rate limiting va auto-scaling konfiguratsiyasiga ehtiyoj borligini ko'rsatadi. API Gateway tomonidagi rate limiter backendni ruxsat etilgan yukdan oshib ketishdan himoya qiladi. Retry policy exponential backoff bilan mijozlarga vaqtinchalik xatolarni to'g'ri boshqarishga yordam beradi.

Load Test uchun asboblar

k6 (Grafana)

k6 — Grafanadan yuk testi uchun yetakchi Open Source vositasi. Skriptlar JavaScript da yoziladi, modul stsenariylar, chegaralar (thresholds) va Prometheus va InfluxDB bilan integratsiya qo'llab-quvvatlanadi. k6 ham CLI da, ham Grafana Cloud k6 bulutida ishlatilishi mumkin. Grafana Cloud Load Test natijalari asosida avtomatik panel quradi va ularni tarixiy ma'lumotlar bilan taqqoslaydi. k6 alohida k6/net/grpc moduli orqali Protocol Buffers va gRPC ni qo'llab-quvvatlaydi.

Apache JMeter

Apache JMeter — grafik interfeysi bilan klassik Load Test vositasi. Keng protokol doirasini qo'llab-quvvatlaydi: HTTP, JDBC, JMS, FTP va TCP. JMeter turli xil so'rov turlari bilan murakkab stsenariylar uchun ko'proq mos keladi, lekin k6 bilan solishtirganda ko'proq qo'lda sozlashni talab qiladi. JMeter Plugins WebSocket va gRPC testi uchun funksionallikni kengaytiradi. Taqsimlangan ishga tushirish uchun JMeter bitta kontroller bilan master-slave arxitekturasidan foydalanadi.

Locust

Locust — Python vositasi bo'lib, yuk stsenariylarini kodda tasvirlash imkonini beradi. Locust Python ni asosiy avtomatlashtirish tili sifatida ishlatadigan jamoalar uchun qulaydir. k6 va JMeterdan farqli o'laroq, Locust qutidan chiqishi bilan taqsimlangan ishga tushirishni qo'llab-quvvatlaydi: bitta master node bir nechta worker nodelarni muvofiqlashtiradi. Taqsimlangan ishga tushirish bir nechta mashinadan 100000 RPS gacha yuk yaratish imkonini beradi. Locust shuningdek maxsus kengaytmalar orqali WebSocket testini qo'llab-quvvatlaydi.

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 yozish namunasi

Yuqoridagi k6 skripti odatiy yuk testi strukturasini namoyish etadi. Options yuk profilini belgilaydi: 100 foydalanuvchiga qadar 2 daqiqa ramp-up, so'ngra 5 daqiqa doimiy yuk va yana 200 foydalanuvchigacha ramp-up. Thresholds testni o'tish mezonlarini belgilaydi: so'rov vaqtining p95 i 500 ms dan ko'p emas, xato foizi 1% dan kam. Chegaralar oshib ketilsa, k6 testni nolga teng bo'lmagan kod bilan tugatadi — bu Load Testni CI/CD ga qo'shish imkonini beradi.

Mobil ilova ishlanmasida server qismining Load Testi qo'shimcha yuk yaratadigan yangi funksiyalar ishga tushirilganda ayniqsa muhimdir: like lar, sharhlar, striming. Tavsiya — ishlab chiqarishga chiqarishdan oldin har bir staging da Load Test o'tkazish. API dizayni bosqichida asosiy yuk profilini yaratish keyingi bosqichlarda arxitektura muammolarining oldini olishga yordam beradi.