Load Test sa Pag-develop ng Mobile — Ano Ito, Mga Scenario, at Paano Isinasagawa

Ano ang Load Test?

Load Test (load testing) ay isang proseso ng pagsusuri kung paano gumagana ang system sa ilalim ng inaasahang bilang ng sabay-sabay na mga request o user. Sa konteksto ng mobile development, ang Load Test ay inilalapat kapwa sa server-side (API, database, cache) at sa client-side (pagproseso ng push notification, pag-sync ng data). Ang pangunahing pagkakaiba mula sa stress testing — ang Load Test ay nagmomodelo ng tunay na load, hindi extreme. Ayon sa AWS Well-Architected Framework (2024), ang load testing ay dapat isagawa gamit ang mga load profile na batay sa real usage analytics.

Ang Load Test ay maaaring isagawa sa antas ng HTTP requests sa API, sa antas ng WebSocket connections, o sa antas ng database transactions. Ang layunin — tiyakin na ang oras ng pagtugon ng bawat request ay hindi lalampas sa itinakdang threshold (karaniwang 500–1000 ms para sa API), at ang throughput capacity (RPS — requests per second) ay umaayon sa mga kinakailangan. Tinutukoy ng Google Cloud Armor (2024) ang mga threshold value batay sa percentiles: ang p95 response time ay hindi dapat lumampas sa 2 segundo para sa mga kritikal na endpoint.

Ang load testing ng mobile backend ay sumasaklaw sa simulation ng mga karaniwang scenario: pagrehistro, pag-authorize, pag-load ng feed, pagpapadala ng form. Ang mga scenario ay nirerecord sa anyo ng HAR files (HTTP Archive) at ginagaya ng load testing tool. Ayon sa dokumentasyon ng k6 (2025), ang HAR conversion ay maaaring mabawasan ang oras ng paghahanda ng Load Test ng hanggang 60%.

Mga Layunin ng Load Testing

Unang layunin ng Load Test — kumpirmasyon ng throughput capacity ng system. Kung ang spec ay nangangailangan ng pagproseso ng 1000 RPS, dapat kumpirmahin ito ng load test na may 20% na reserba. Ayon sa Netflix Tech Blog (2024), ang load testing sa Netflix ay isinasagawa na may 2x na reserba mula sa peak load: kung inaasahan ang 10000 RPS, sinusuri ng test ang 20000 RPS. Tinitiyak ng pamamaraang ito ang stability sa biglaang pagtaas ng trapiko.

Pangalawang layunin — pagtukoy ng mga bottleneck sa arkitektura. Karaniwang bottleneck sa mobile backends — database (mabagal na query), cache (maling invalidation strategy), at external API (mabagal na third-party services). Distributed tracing (Jaeger, Zipkin) ay tumutulong upang i-localize ang problema sa antas ng isang partikular na serbisyo o request.

Pangatlong layunin — pagtukoy ng saturation point. Ito ang sandali kung kailan ang pagdagdag ng mga bagong user ay hindi na nagpapataas ng throughput capacity. Sa mga mobile application, ang saturation point ay kadalasang naaabot sa 70–80% CPU load sa mga database server. Auto-scaling ay dapat gumana bago maabot ang puntong ito.

Mga Scenario ng Load Testing

Peak Load (Spike Test) — nagmomodelo ng biglaang pagtaas ng aktibidad, halimbawa umagang push notification o paglulunsad ng advertising campaign. Ayon sa Grafana k6 (2025), ang Spike Test ay nag-simulate ng pagtaas ng load mula 100 hanggang 10000 RPS sa loob ng 30 segundo. Dapat kayang hawakan ito ng system nang walang pagkawala ng mga request at hindi lalampas sa oras ng pagtugon ng higit sa 50%.

Constant Load (Endurance Test) — pagsusuri ng stability ng system sa pangmatagalang operasyon sa ilalim ng load. Karaniwang tagal — 1–4 na oras. Inilalahad ng Endurance Test ang memory leaks sa server applications, mga problema sa database connection pool, at degradation ng cache performance. Connection pool ng PostgreSQL sa ilalim ng mahabang load na walang tamang configuration ay maaaring maubos ang mga available na koneksyon sa loob ng 2–3 oras ng operasyon.

Step Load (Step Load Test) — unti-unting pagtaas ng load na may hakbang na 10–20% bawat 2–5 minuto. Ang scenario na ito ay tumutulong upang mahanap ang eksaktong hangganan pagkatapos kung saan ang system ay nagde-degrade. InfluxDB at Prometheus ay nangongolekta ng mga metrik sa bawat hakbang upang bumuo ng graph ng dependence ng response time sa RPS.

Mga Metrik ng Load Test

Oras ng Pagtugon

Oras ng Pagtugon (Response Time) — pangunahing metrik ng Load Test. Sinusukat sa millisecond at sinusuri batay sa percentiles: p50 (median), p95, at p99. Inirerekomenda ng Google SRE (2024) ang threshold p95 na hindi hihigit sa 1000 ms para sa REST API at hindi hihigit sa 200 ms para sa gRPC. Mas mahalaga ang percentiles kaysa average dahil ipinapakita nila ang pag-uugali ng pinakamalalang mga request na unang napapansin ng mga user. Apdex (Application Performance Index) — composite metric na isinasaalang-alang ang proporsyon ng nasisiyahan, nagtitiis, at nabigo na mga user.

Throughput Capacity

Throughput Capacity (Throughput) — bilang ng matagumpay na request bawat unit ng oras. Sinusukat sa RPS (requests per second) o TPS (transactions per second). Ang Throughput graph sa coordinates “oryas — RPS” ay dapat linear hanggang sa saturation point. Biglang pagbaba ng Throughput sa pagtaas ng load — tanda ng pag-abot sa limitasyon ng system. Apache Bench at wrk — mga simpleng CLI tool para sa mabilisang pagsusuri ng Throughput sa yugto ng pag-develop.

Porsyento ng Error

Porsyento ng Error (Error Rate) — proporsyon ng mga response na may HTTP status 4xx o 5xx mula sa kabuuang bilang ng mga request. Pinapayagang threshold — mas mababa sa 1%. Ang mga error 429 (Too Many Requests) at 503 (Service Unavailable) sa ilalim ng mataas na load ay nagpapahiwatig ng pangangailangan para sa configuration ng rate limiting at auto-scaling. Pinoprotektahan ng Rate limiter sa gilid ng API Gateway ang backend mula sa paglampas sa pinapayagang load. Retry policy na may exponential backoff ay tumutulong sa mga client na maayos na mahawakan ang mga pansamantalang error.

Mga Tool para sa Load Test

k6 (Grafana)

k6 — nangungunang Open Source tool para sa load testing mula sa Grafana. Ang mga script ay isinusulat sa JavaScript, sumusuporta sa modular scenarios, thresholds, at integration sa Prometheus at InfluxDB. Ang k6 ay maaaring patakbuhin sa CLI o sa cloud Grafana Cloud k6. Grafana Cloud ay awtomatikong bumubuo ng mga dashboard batay sa mga resulta ng Load Test at ikinukumpara ang mga ito sa historical data. Ang k6 ay sumusuporta sa Protocol Buffers at gRPC sa pamamagitan ng hiwalay na modyul na k6/net/grpc.

Apache JMeter

Apache JMeter — klasikong tool para sa Load Test na may graphical interface. Sumusuporta sa malawak na hanay ng mga protocol: HTTP, JDBC, JMS, FTP, at TCP. Ang JMeter ay mas angkop para sa mga komplikadong scenario na may maraming iba't ibang uri ng request, ngunit nangangailangan ng mas maraming manual configuration kumpara sa k6. JMeter Plugins ay nagpapalawak ng functionality para sa WebSocket at gRPC testing. Para sa distributed execution, ang JMeter ay gumagamit ng master-slave architecture na may isang controller.

Locust

Locust — tool na nakabatay sa Python na nagbibigay-daan upang ilarawan ang load scenarios sa code. Ang Locust ay maginhawa para sa mga koponan na gumagamit ng Python bilang pangunahing wika para sa automation. Hindi tulad ng k6 at JMeter, ang Locust ay sumusuporta sa distributed execution nang out-of-the-box: isang master-node ang nag-coordinate ng ilang worker-node. Distributed execution ay nagbibigay-daan upang makabuo ng load hanggang 100000 RPS mula sa maraming makina. Ang Locust ay sumusuporta rin sa WebSocket testing sa pamamagitan ng custom extensions.

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

Halimbawa ng Pagsulat ng Load Test sa k6

Ang script ng k6 sa itaas ay nagpapakita ng karaniwang istraktura ng load test. Tinutukoy ng Options ang load profile: ramp-up 2 minuto hanggang 100 user, pagkatapos 5 minuto ng constant load at ramp-up muli hanggang 200 user. Thresholds ay nagtatakda ng pamantayan ng pagpasa ng test: p95 ng request time ay hindi hihigit sa 500 ms, porsyento ng error ay mas mababa sa 1%. Kung lumampas ang thresholds, tinatapos ng k6 ang test na may non-zero code — ito ay nagbibigay-daan sa integration ng Load Test sa CI/CD.

Sa mobile development, ang Load Test ng server-side ay lalong mahalaga kapag naglulunsad ng mga bagong feature na lumilikha ng karagdagang load: likes, comments, streaming. Rekomendasyon — magsagawa ng Load Test sa bawat staging bago i-deploy sa production. Ang paggawa ng baseline load profile sa yugto ng pagdidisenyo ng API ay tumutulong upang maiwasan ang mga problema sa arkitektura sa mga huling yugto.