Mobil ishlab chiqishda Stress Test: nima, maqsadlari va qanday o'tkaziladi

Stress Test nima?

Stress Test (stress testi) — hisoblangan parametrlardan oshib ketadigan sharoitlarda tizimning ishlash qobiliyatini baholash jarayonidir. Mobil ilova uchun bu me'yorda 1000 bo'lgan holda 10000 bir vaqtning o'zida push bildirishnomalari, backend uchun — kutilgan 5000 RPS o'rniga 50000 RPS degani bo'lishi mumkin. Stress Testning Load Testdan asosiy farqi shundaki, maqsad ishlashni tasdiqlash emas, balki tizimning loyiha quvvatidan tashqaridagi xatti-harakatini o'rganishdir. Netflix Engineering (2024) Stress Testni “tizimning oldindan bashorat qilinadigan tarzda ishdan chiqishi haqidagi gipotezani tekshirish” deb ta'riflaydi.

Stress testi ikkita majburiy bosqichni o'z ichiga oladi: ishlamay qolguncha yuklash va tiklanishni kuzatish. Tiklanish (recovery) — yuk olib tashlanganidan keyin tizimning normal ishga qaytish qobiliyatidir. Qayta ishga tushirmasdan tiklanmaydigan tizim, hatto qisqa muddatli ortiqcha yukka bardosh bersa ham, mo'rt hisoblanadi. AWS Well-Architected Framework (2024) ga ko'ra, Stress Testdan keyin tiklanish vaqti 5 daqiqadan oshmasligi kerak.

Mobil mijozlar uchun Stress Test jarayonlarning majburiy tugatilishi, tarmoqning uzilishi va RAM xotirasining tugashi sharoitida ishlashni tekshirishni o'z ichiga oladi. Android Low Memory Killer RAM etishmovchiligi paytida fon jarayonini tugatishi mumkin — stress testi ilova bunday tugatishdan keyin holatni to'g'ri tiklashini tekshirishi kerak. Apple UIKit (2024) ilovaning har bir ekranida memory warning stsenariylarini tekshirishni tavsiya qiladi.

Stress testining maqsadlari

Ishlamay qolish nuqtasini aniqlash

Stress Testning birinchi maqsadi — ishlamay qolish nuqtasini aniqlash (breaking point). Bu asosiy ishlash ko'rsatkichlaridan biri tanqidiy chegaradan oshib ketgan paytdir: p95 javob vaqti 10 soniyadan oshadi, HTTP 5XX xatolik foizi 5% dan oshadi yoki o'tkazish qobiliyati baseline dan 50% ga tushadi. Ishlamay qolish nuqtasini qayd etish jamoaga tizimning masshtablash chegarasini oldindan bilish imkonini beradi. Capacity planning aynan Stress Test ma'lumotlariga tayanadi, Load Testga emas, chunki Load Test chegara shartlarini tekshirmaydi.

Tiklanish mexanizmlarini tekshirish

Ikkinchi maqsad — tiklanish mexanizmlarini tekshirish. Yuk normal darajaga tushgandan so'ng, tizim standart ko'rsatkichlarga qaytishi kerak. Ma'lumotlar bazasiga ulanishlar havosi bo'shatilmasa yoki kesh bekor qilinmasa, Stress Test bu muammoni aniqlaydi. Circuit breaker (Hystrix, Resilience4j) ortiqcha yuk paytida ishga tushishi va barqarorlashgandan keyin aloqani avtomatik tiklash kerak. Health check endpointlari test davomida har bir xizmatning holatini kuzatishga yordam beradi.

Auto-scalingni tekshirish

Uchinchi maqsad — auto-scalingni tekshirish. Infratuzilma Kubernetes yoki AWS Auto Scaling dan foydalansa, Stress Test yangi podlar yoki instansiyalar yetarlicha tez yaratilishini tekshiradi. Google Kubernetes Engine (2024) ga ko'ra, HPA (Horizontal Pod Autoscaler) metrikasi ishga tushgan paytdan boshlab yangi podni joylashtirish vaqti 30 soniyadan oshmasligi kerak. HPA CPU, xotira va moslashtirilgan metrikalar asosida masshtablanishi kerak. Cluster Autoscaler mavjud tugunlar podlarni sig'dira olmasa, yangi tugunlar qo'shadi.

Stress Test metodologiyasi

Bosqichma-bosqich yuk oshirish (Ramp-up Stress Test) — eng keng tarqalgan stsenariy. Dastlabki yuk kutilganning 50% darajasida o'rnatiladi, so'ngra har 2 daqiqada tizim ishlamay qolguncha 10% ga oshiriladi. Bu stsenariy barqarorlikning aniq chegarasini topish imkonini beradi. Grafana Cloud k6 (2025) silliq javob vaqti grafigini olish uchun oshirish qadamining 10% dan oshmasligini tavsiya qiladi.

Keskin yuk sakrashi (Spike Stress Test) — yuk 10-30 soniya ichida 10% dan 500% gacha oshadi. Bu stsenariy virusli kontent tarqalishi yoki DDoS hujumi kabi vaziyatlarni modellashtiradi. Spike Stress Test ishlashdan ko'ra tizimning hayotiyligini tekshiradi: to'liq ishdan chiqmaslik va barqarorlashgandan keyin ishga qaytish qobiliyati. API Gateway keskin sakrashlardan backendni himoya qilish uchun rate limiting konfiguratsiya qilishi kerak.

Uzoq muddat yukni ushlab turish (Sustained Stress Test) — tizim 30-60 daqiqa davomida ortiqcha yuk holatida ushlab turiladi. Bu stsenariy qisqa muddatli testlarda namoyon bo'lmaydigan resurs oqishlarini aniqlaydi. Xotira oqishi Java/Kotlin ilovalarida 20-40 daqiqa intensiv ish davomida to'planadi va faqat Sustained Stress Test uni aniqlaydi.

Ishlamay qolish nuqtasi va tiklanish tahlili

Ishlamay qolish nuqtasi uchta mezon bo'yicha aniqlanadi: javob vaqti, xatolik foizi va o'tkazish qobiliyati. Odatda birinchi bo'lib javob vaqti chegarasi oshib ketadi — so'rovlar belgilangan limitdan uzoqroq bajarila boshlaydi. So'ngra xatolik foizi oshadi: server so'rovlarni qayta ishlashga ulgurmaydi va 503 qaytaradi. Oxirgi bo'lib Throughput tushadi — tizim hatto minimal yukni ham uddalay olmaydi. Metrika ishlamay qolish nuqtasi quvvatni rejalashtirish uchun yuk profilida qayd etiladi.

Tiklanish tahlili uch fazani o'z ichiga oladi: zudlik bilan reaksiya (yuk olib tashlanganidan keyin birinchi 30 soniya), barqarorlashish (1-5 daqiqa) va to'liq tiklanish (5-30 daqiqa). Zudlik bilan reaksiya fazasida javob vaqti baseline dan pastga tushishi kerak — tizim navbatlardan bo'shaydi. Agar bu sodir bo'lmasa, muammo yukda emas, balki to'plangan holatdadir. Graceful degradation — tizimning ortiqcha yuk paytida qisman funksionallikni saqlash qobiliyati — arxitektura yetukligining asosiy ko'rsatkichidir.

Chaos Engineering Stress Testni qasddan nosozliklar kiritish bilan to'ldiradi: ma'lumotlar bazasi serverini o'chirish, tarmoq kechikishi, mikroxizmatni to'xtatish. Netflix dan Chaos Monkey (2024) ishlab chiqarishda tasodifiy jarayonlarni tugatadi, tizimning chidamliligini tekshiradi. Mobil ilovalar uchun Chaos Engineering stsenariylarni tekshirishni anglatadi: tarmoq yo'qligi, API mavjud emasligi, bo'sh server javobi.

Stress Test uchun vositalar

k6 ramping-arrival-rate bilan

k6 ramping-arrival-rate konfiguratsiyasi bilan `execution` moduli orqali Stress Testni qo'llab-quvvatlaydi. Bu rejim har bir so'rovning bajarilish vaqtidan qat'iy nazar sekundiga so'rovlar sonini oshiradi. Load Test bilan solishtirganda, k6 da Stress Test agressiv thresholds o'rnatishni va keskin nosozlikni simulyatsiya qilish uchun gracefull-stopni o'chirishni talab qiladi. Grafana Cloud javob vaqti grafigining egilishiga qarab ishlamay qolish nuqtasini avtomatik aniqlaydi. Kubernetes uchun k6-operator klasterdan taqsimlangan Stress Testlarni ishga tushirish imkonini beradi.

Ultimate Thread Group bilan JMeter

JMeter Ultimate Thread Group — jadval shaklida yuk profilini belgilaydigan plagina orqali Stress Testni konfiguratsiya qilish imkonini beradi: oqimlar soni, isinish vaqti, ushlab turish vaqti, pasayish vaqti. Ultimate Thread Group murakkab ko'p fazali stsenariylar uchun qulaydir. JMeter Backend Listener ishlamay qolish nuqtasi grafiklarini qurish uchun metrikalarni InfluxDB ga yuboradi. Stress Test uchun JMeter da ortiqcha yuk paytida xatti-harakatni aniqroq o'lchash uchun ulanish time-outlarini o'chirish tavsiya etiladi.

Chaos Engineering uchun Gremlin

Gremlin — infratuzilmaning Stress Testi uchun Chaos Engineering platformasi. Gremlin tarmoqni uzish, CPU ni yuklash, diskni to'ldirish va alohida Kubernetes podlari darajasida jarayonlarni tugatish imkonini beradi. SRE jamoalari kompleks Stress Test uchun Gremlinni k6 bilan birga ishlatadi: k6 yuk yaratadi, Gremlin nosozliklar kiritadi. Game Day — “caos report” da hujjatlashtiriladigan Gremlin bilan muntazam Stress Test sessiyalari.

k6 da Stress Test namunasi

k6 da taqdim etilgan skript ishlamay qolguncha bosqichma-bosqich yuk oshirish bilan Stress Testni namoyish etadi. Ramping-arrival-rate bajarilish vaqtidan qat'iy nazar sekundiga so'rovlar sonini oshiradi. Thresholds degradatsiyani agressiv aniqlash uchun o'rnatilgan: p95 2000 ms dan ko'p emas, error rate 5% dan ko'p emas. Chegaralar oshib ketganda k6 testni xato kodi bilan tugatadi, bu Stress Testni CI/CD pipeline ga kiritish imkonini beradi.

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 testining eng yaxshi amaliyotlari

Stress Testni staging da boshlang — ishlab chiqarishda stress testi ilg'or monitoring va qaytarish rejasini talab qiladi. Google SRE (2024) arxitektura va quvvat jihatidan ishlab chiqarishni takrorlaydigan 100% izolyatsiya qilingan muhitda Stress Test o'tkazishni tavsiya qiladi. Staging da muvaffaqiyatli testdan so'ng SRE nazorati ostida ishlab chiqarishga o'tish mumkin. Ortiqcha yuk paytida funksionallikni o'chirish uchun Feature flag majburiy elementdir.

Stress Testni CI/CD da avtomatlashtiring ishlamay qolish nuqtasining regressiya tahlili uchun. Ilovaning yangi versiyasi avvalgisidan 20% past ishlamay qolish nuqtasiga ega bo'lsa, bu chiqarilishdan oldin tuzatilishi kerak bo'lgan regressiyadir. Baseline breaking point metrikalarda saqlanadi va har bir Stress Test natijasi bilan avtomatik taqqoslanadi. Ishlamay qolish nuqtasi 10% tushganda alert ishga tushadi.

Har bir Stress Testni hujjatlashtiring: yuk profili, ishlamay qolish nuqtasi, tiklanish xatti-harakati va aniqlangan muammolar ro'yxati. Netflix Engineering (2024) “Game Day” — natijalari “caos report” da hujjatlashtiriladigan muntazam Stress Test sessiyalarini o'tkazadi. Hisobot stress testi haqida belgilangan ishlamay qolish nuqtasi bilan “RPS — javob vaqti” grafigini o'z ichiga olishi kerak.