Stress Test sa mobile development: ano ito, mga layunin at paano isinasagawa

Ano ang Stress Test?

Stress Test (stress testing) ay ang proseso ng pagsusuri sa kakayahan ng sistema na gumana sa mga kondisyong lumalagpas sa kinakalkulang mga parameter. Para sa isang mobile application, ito ay maaaring mangahulugan ng 10000 sabay-sabay na push notification sa normang 1000, para sa backend — 50000 RPS sa inaasahang 5000. Ang pangunahing pagkakaiba ng Stress Test sa Load Test ay ang layunin ay hindi ang kumpirmahin ang pagganap, kundi ang pag-aralan ang pag-uugali ng sistema lampas sa dinisenyo nitong kapasidad. Tinutukoy ng Netflix Engineering (2024) ang Stress Test bilang “pagsubok sa hipotesis na ang sistema ay mabibigo sa isang mahuhulaan na paraan”.

Ang stress testing ay may dalawang sapilitang yugto: pagkarga hanggang sa pagkabigo at obserbasyon ng pagbawi. Pagbawi (recovery) ay ang kakayahan ng sistema na bumalik sa normal na operasyon pagkatapos alisin ang labis na karga. Ang sistemang hindi bumabangon nang walang restart ay itinuturing na marupok, kahit na makatiis ito ng panandaliang labis na karga. Ayon sa AWS Well-Architected Framework (2024), ang oras ng pagbawi pagkatapos ng Stress Test ay hindi dapat lumagpas sa 5 minuto.

Para sa mga mobile client, ang Stress Test ay may kasamang pagsusuri ng operasyon sa ilalim ng sapilitang pagtatapos ng mga proseso, pagputol ng network, at pagkaubos ng RAM. Android Low Memory Killer ay maaaring magtapos ng background na proseso kapag kulang ang RAM — dapat suriin ng stress test kung ang application ay wastong bumabangon pagkatapos ng naturang pagtatapos. Inirerekomenda ng Apple UIKit (2024) na subukan ang mga senaryo ng memory warning sa bawat screen ng application.

Mga layunin ng stress testing

Pagtukoy sa punto ng pagkabigo

Ang unang layunin ng Stress Test — pagtukoy sa punto ng pagkabigo (breaking point). Ito ang sandali kung kailan ang isa sa mga pangunahing tagapagpahiwatig ng pagganap ay lumalagpas sa kritikal na hangganan: oras ng tugon p95 ay lumalagpas sa 10 segundo, porsyento ng mga error HTTP 5XX ay lumalagpas sa 5%, o throughput ay bumababa sa ibaba 50% ng baseline. Ang pagtatala ng punto ng pagkabigo ay nagbibigay-daan sa team na malaman nang maaga ang hangganan ng skalabilidad ng sistema. Capacity planning ay umaasa sa datos mula sa Stress Test, hindi sa Load Test, dahil ang Load Test ay hindi sumusuri sa mga kondisyong hangganan.

Pagsusuri ng mga mekanismo ng pagbawi

Ang ikalawang layunin — pagsusuri ng mga mekanismo ng pagbawi. Pagkatapos bumaba ang karga sa normal na antas, ang sistema ay dapat bumalik sa karaniwang mga tagapagpahiwatig. Kung ang pool ng koneksyon sa database ay hindi nailalabas o ang cache ay hindi nai-invalidate, ilalantaw ng Stress Test ang problemang ito. Ang circuit breaker (Hystrix, Resilience4j) ay dapat umaktibo sa labis na karga at awtomatikong ibalik ang koneksyon pagkatapos ng stabilisasyon. Health check endpoints ay tumutulong sa pagmonitor ng estado ng bawat serbisyo sa panahon ng pagsubok.

Balidasyon ng auto-scaling

Ang ikatlong layunin — balidasyon ng auto-scaling. Kung ang imprastraktura ay gumagamit ng Kubernetes o AWS Auto Scaling, sinusuri ng Stress Test kung ang mga bagong pod o instance ay nalikha nang sapat na mabilis. Ayon sa Google Kubernetes Engine (2024), ang oras ng pag-deploy ng bagong pod ay hindi dapat lumagpas sa 30 segundo mula sa pag-activate ng metrik ng HPA (Horizontal Pod Autoscaler). HPA ay dapat mag-scale batay sa CPU, memory, at custom na metrik. Ang Cluster Autoscaler ay nagdaragdag ng mga bagong node kung ang kasalukuyang mga node ay hindi kayang tumanggap ng mga pod.

Metodolohiya ng Stress Test

Unti-unting pagtaas ng karga (Ramp-up Stress Test) — ang pinakakaraniwang senaryo. Ang unang karga ay itinakda sa 50% ng inaasahan, pagkatapos bawat 2 minuto ay tumataas ng 10% hanggang sa mabigo ang sistema. Ang senaryong ito ay nagpapahintulot na mahanap ang eksaktong hangganan ng katatagan. Grafana Cloud k6 (2025) ay nagrerekomenda ng hakbang ng pagtaas na hindi hihigit sa 10% para sa makinis na grapiko ng oras ng tugon.

Biglaang pagtalon ng karga (Spike Stress Test) — ang karga ay tumataas mula 10% hanggang 500% sa loob ng 10–30 segundo. Ang senaryong ito ay nagmomodelo ng mga sitwasyon tulad ng viral na pagkalat ng nilalaman o DDoS attack. Ang Spike Stress Test ay hindi gaanong sumusuri sa pagganap kundi sa sigla ng sistema: kakayahang hindi tuluyang bumagsak at bumalik sa operasyon pagkatapos ng stabilisasyon. API Gateway ay dapat mag-configure ng rate limiting para protektahan ang backend mula sa biglaang pagtalon.

Matagalang pagpapanatili ng labis na karga (Sustained Stress Test) — ang sistema ay pinananatili sa estado ng labis na karga sa loob ng 30–60 minuto. Ang senaryong ito ay naglalantad ng mga leak ng resources na hindi lumilitaw sa panandaliang pagsubok. Memory leak sa mga Java/Kotlin application ay naipon sa loob ng 20–40 minuto ng intensibong trabaho at tanging Sustained Stress Test ang nakakatuklas nito.

Pagsusuri ng punto ng pagkabigo at pagbawi

Punto ng pagkabigo ay tinutukoy batay sa tatlong kriterya: oras ng tugon, porsyento ng error, at throughput. Karaniwang unang nalalampasan ang hangganan ng oras ng tugon — ang mga kahilingan ay nagsisimulang isagawa nang mas matagal kaysa sa itinakdang limitasyon. Pagkatapos ay tumataas ang porsyento ng error: ang server ay hindi na kayang iproseso ang mga kahilingan at nagbabalik ng 503. Huling bumababa ang Throughput — ang sistema ay hindi na kaya kahit ang minimal na karga. Metrik ng punto ng pagkabigo ay itinatala sa profile ng karga para sa pagpaplano ng kapasidad.

Pagsusuri ng pagbawi ay may tatlong yugto: agarang reaksyon (unang 30 segundo pagkatapos alisin ang karga), stabilisasyon (1–5 minuto), at buong pagbawi (5–30 minuto). Sa yugto ng agarang reaksyon, ang oras ng tugon ay dapat bumaba sa ibaba ng baseline — ang sistema ay lumalaya mula sa mga pila. Kung hindi ito mangyari, ang problema ay hindi sa karga kundi sa naipong estado. Graceful degradation — kakayahan ng sistema na mapanatili ang bahagyang functionality sa ilalim ng labis na karga — ay pangunahing tagapagpahiwatig ng kapanahunan ng arkitektura.

Ang Chaos Engineering ay nagpupuno sa Stress Test sa pamamagitan ng sadyang pagpapakilala ng mga pagkabigo: pagpatay sa server ng database, pagkaantala ng network, pagtigil ng microservice. Chaos Monkey mula sa Netflix (2024) ay random na nagtatapos ng mga proseso sa produksyon, sinusuri ang katatagan ng sistema. Para sa mga mobile application, ang Chaos Engineering ay nangangahulugan ng pagsubok ng mga senaryo: walang network, hindi available ang API, walang laman na tugon ng server.

Mga kasangkapan para sa Stress Test

k6 na may ramping-arrival-rate

k6 ay sumusuporta sa Stress Test sa pamamagitan ng `execution` module na may ramping-arrival-rate configuration. Ang mode na ito ay nagpapataas ng bilang ng mga kahilingan bawat segundo nang hindi nakadepende sa oras ng pag-execute ng bawat kahilingan. Kumpara sa Load Test, ang Stress Test sa k6 ay nangangailangan ng pagtatakda ng mas agresibong thresholds at pag-disable ng gracefull-stop para sa simulasyon ng biglaang pagkabigo. Awtomatikong natutukoy ng Grafana Cloud ang punto ng pagkabigo batay sa pagbasag ng grapiko ng oras ng tugon. k6-operator para sa Kubernetes ay nagpapahintulot ng pagpapatakbo ng distributed Stress Test mula sa cluster.

JMeter na may Ultimate Thread Group

JMeter ay nagpapahintulot ng configuration ng Stress Test sa pamamagitan ng Ultimate Thread Group — isang plugin na tumutukoy sa profile ng karga sa anyo ng talahanayan: bilang ng threads, oras ng pag-init, oras ng pagpapanatili, oras ng pagbaba. Ang Ultimate Thread Group ay maginhawa para sa kumplikadong multi-phase na senaryo. JMeter Backend Listener ay nagpapadala ng mga metrik sa InfluxDB para sa pagbuo ng mga grapiko ng punto ng pagkabigo. Para sa Stress Test sa JMeter, inirerekomenda na i-disable ang connection timeouts upang mas tumpak na masukat ang pag-uugali sa ilalim ng labis na karga.

Gremlin para sa Chaos Engineering

Gremlin — platform ng Chaos Engineering para sa Stress Test ng imprastraktura. Pinapayagan ng Gremlin na patayin ang network, ikarga ang CPU, punan ang disk, at tapusin ang mga proseso sa antas ng indibidwal na Kubernetes pod. Ginagamit ng mga SRE team ang Gremlin kasama ng k6 para sa komprehensibong Stress Test: ang k6 ay lumilikha ng karga, ang Gremlin ay nagpapakilala ng mga pagkabigo. Game Day — regular na sesyon ng Stress Test gamit ang Gremlin na idodokumento sa “report ng chaos” para sa pagsusuri ng katatagan ng sistema.

Halimbawa ng Stress Test sa k6

Ang ipinakitang script sa k6 ay nagpapakita ng Stress Test na may unti-unting pagtaas ng karga hanggang sa pagkabigo. Ramping-arrival-rate ay nagpapataas ng bilang ng mga kahilingan bawat segundo nang hindi nakadepende sa oras ng pag-execute. Ang thresholds ay nakatakda para sa agresibong pagtuklas ng degradasyon: p95 hindi hihigit sa 2000 ms, error rate hindi hihigit sa 5%. Kapag nalampasan ang mga hangganan, tinatapos ng k6 ang pagsubok na may error code, na nagpapahintulot na isama ang Stress Test sa CI/CD pipeline.

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,
    })
}

Mga pinakamahusay na kasanayan sa stress testing

Simulan ang Stress Test sa staging — ang stress testing sa produksyon ay nangangailangan ng advanced na monitoring at rollback plan. Inirerekomenda ng Google SRE (2024) na isagawa ang Stress Test sa 100% isolated na environment na ginagaya ang produksyon sa arkitektura at kapasidad. Pagkatapos ng matagumpay na pagsubok sa staging, maaaring lumipat sa produksyon sa ilalim ng pangangasiwa ng SRE. Feature flag para sa pag-disable ng functionality sa ilalim ng labis na karga ay sapilitang elemento.

I-automate ang Stress Test sa CI/CD para sa regression analysis ng punto ng pagkabigo. Kung ang bagong bersyon ng application ay may punto ng pagkabigo na 20% mas mababa kaysa sa nauna, ito ay regression na kailangang ayusin bago ang release. Baseline breaking point ay iniimbak sa mga metrik at awtomatikong ikinukumpara sa resulta ng bawat Stress Test. Ang alert ay naa-activate kapag ang punto ng pagkabigo ay bumaba ng 10%.

Idokumento ang bawat Stress Test: profile ng karga, punto ng pagkabigo, pag-uugali ng pagbawi, at listahan ng mga natuklasang problema. Ang Netflix Engineering (2024) ay nagsasagawa ng “Game Day” — regular na sesyon ng Stress Test na ang mga resulta ay idodokumento sa “report ng chaos”. Ulat ng stress testing ay dapat maglaman ng grapiko “RPS — oras ng tugon” na may markadong punto ng pagkabigo.