Load Test dalam Pengembangan Mobile — Apa Itu, Skenario, dan Cara Melakukannya

Apa itu Load Test?

Load Test (pengujian beban) adalah proses pemeriksaan bagaimana sistem bekerja di bawah jumlah permintaan atau pengguna simultan yang diharapkan. Dalam konteks pengembangan mobile, Load Test diterapkan baik pada sisi server (API, database, cache) maupun sisi klien (pemrosesan push-notifikasi, sinkronisasi data). Perbedaan utama dari stress testing — Load Test memodelkan beban nyata, bukan ekstrem. Menurut AWS Well-Architected Framework (2024), pengujian beban harus dilakukan menggunakan profil beban yang didasarkan pada analitik penggunaan nyata.

Load Test dapat dilakukan pada tingkat permintaan HTTP ke API, pada tingkat koneksi WebSocket, atau pada tingkat transaksi database. Tujuannya — memastikan waktu respons setiap permintaan tidak melebihi ambang batas yang ditentukan (biasanya 500–1000 ms untuk API), dan kapasitas throughput (RPS — requests per second) sesuai dengan persyaratan. Google Cloud Armor (2024) menentukan nilai ambang berdasarkan persentil: p95 waktu respons tidak boleh melebihi 2 detik untuk endpoint kritis.

Pengujian beban backend mobile mencakup simulasi skenario umum: registrasi, otorisasi, memuat feed, mengirim formulir. Skenario direkam dalam bentuk file HAR (HTTP Archive) dan direproduksi oleh alat pengujian beban. Menurut dokumentasi k6 (2025), konversi HAR dapat mengurangi waktu persiapan Load Test hingga 60%.

Tujuan Pengujian Beban

Tujuan pertama Load Test — konfirmasi kapasitas throughput sistem. Jika spesifikasi membutuhkan penanganan 1000 RPS, pengujian beban harus mengonfirmasi hal ini dengan cadangan 20%. Menurut Netflix Tech Blog (2024), pengujian beban di Netflix dilakukan dengan cadangan 2x dari beban puncak: jika diharapkan 10000 RPS, pengujian memeriksa 20000 RPS. Pendekatan ini menjamin stabilitas saat lonjakan lalu lintas mendadak.

Tujuan kedua — identifikasi hambatan (bottlenecks) dalam arsitektur. Hambatan umum di backend mobile — database (permintaan lambat), cache (strategi invalidasi yang salah), dan API eksternal (layanan pihak ketiga yang lambat). Distributed tracing (Jaeger, Zipkin) membantu melokalisasi masalah pada tingkat layanan atau permintaan tertentu.

Tujuan ketiga — penentuan titik jenuh (saturation point). Ini adalah saat ketika penambahan pengguna baru berhenti meningkatkan kapasitas throughput. Dalam aplikasi mobile, titik jenuh sering tercapai pada 70–80% beban CPU di server database. Auto-scaling harus aktif sebelum mencapai titik ini.

Skenario Pengujian Beban

Beban Puncak (Spike Test) — memodelkan lonjakan aktivitas mendadak, misalnya pengiriman push-notifikasi pagi atau peluncuran kampanye iklan. Menurut Grafana k6 (2025), Spike Test mensimulasikan pertumbuhan beban dari 100 hingga 10000 RPS dalam 30 detik. Sistem harus menanganinya tanpa kehilangan permintaan dan tanpa melebihi waktu respons lebih dari 50%.

Beban Konstan (Endurance Test) — pemeriksaan stabilitas sistem selama operasi jangka panjang di bawah beban. Durasi umum — 1–4 jam. Endurance Test mengungkap kebocoran memori di aplikasi server, masalah dengan pool koneksi database, dan degradasi kinerja cache. Pool koneksi PostgreSQL di bawah beban panjang tanpa konfigurasi yang benar dapat menghabiskan koneksi yang tersedia dalam 2–3 jam operasi.

Beban Bertahap (Step Load Test) — peningkatan beban bertahap dengan langkah 10–20% setiap 2–5 menit. Skenario ini membantu menemukan batas pasti setelah sistem terdegradasi. InfluxDB dan Prometheus mengumpulkan metrik pada setiap langkah untuk membangun grafik ketergantungan waktu respons terhadap RPS.

Metrik Load Test

Waktu Respons

Waktu Respons (Response Time) — metrik utama Load Test. Diukur dalam milidetik dan dianalisis berdasarkan persentil: p50 (median), p95, dan p99. Google SRE (2024) merekomendasikan ambang p95 tidak lebih dari 1000 ms untuk REST API dan tidak lebih dari 200 ms untuk gRPC. Persentil lebih penting daripada rata-rata karena menunjukkan perilaku permintaan terburuk yang pertama kali diperhatikan pengguna. Apdex (Application Performance Index) — metrik gabungan yang memperhitungkan proporsi pengguna yang puas, toleran, dan kecewa.

Kapasitas Throughput

Kapasitas Throughput (Throughput) — jumlah permintaan berhasil per unit waktu. Diukur dalam RPS (requests per second) atau TPS (transactions per second). Grafik Throughput dalam koordinat “waktu — RPS” harus linear hingga titik jenuh. Penurunan tajam Throughput saat peningkatan beban — tanda tercapainya batas sistem. Apache Bench dan wrk — alat CLI sederhana untuk pemeriksaan cepat Throughput pada tahap pengembangan.

Persentase Kesalahan

Persentase Kesalahan (Error Rate) — proporsi respons dengan status HTTP 4xx atau 5xx dari total jumlah permintaan. Ambang yang diizinkan — kurang dari 1%. Kesalahan 429 (Too Many Requests) dan 503 (Service Unavailable) di bawah beban tinggi menunjukkan perlunya konfigurasi rate limiting dan auto-scaling. Rate limiter di sisi API Gateway melindungi backend dari melebihi beban yang diizinkan. Retry policy dengan exponential backoff membantu klien menangani kesalahan sementara dengan benar.

Alat untuk Load Test

k6 (Grafana)

k6 — alat Open Source terkemuka untuk pengujian beban dari Grafana. Skrip ditulis dalam JavaScript, mendukung skenario modular, ambang batas (thresholds), dan integrasi dengan Prometheus dan InfluxDB. k6 dapat dijalankan baik di CLI maupun di cloud Grafana Cloud k6. Grafana Cloud secara otomatis membangun dasbor berdasarkan hasil Load Test dan membandingkannya dengan data historis. k6 mendukung Protocol Buffers dan gRPC melalui modul terpisah k6/net/grpc.

Apache JMeter

Apache JMeter — alat klasik untuk Load Test dengan antarmuka grafis. Mendukung berbagai protokol: HTTP, JDBC, JMS, FTP, dan TCP. JMeter lebih cocok untuk skenario kompleks dengan berbagai jenis permintaan, tetapi membutuhkan lebih banyak konfigurasi manual dibandingkan k6. JMeter Plugins memperluas fungsionalitas untuk pengujian WebSocket dan gRPC. Untuk eksekusi terdistribusi, JMeter menggunakan arsitektur master-slave dengan satu controller.

Locust

Locust — alat berbasis Python yang memungkinkan mendeskripsikan skenario beban dalam kode. Locust nyaman untuk tim yang menggunakan Python sebagai bahasa utama untuk otomatisasi. Berbeda dengan k6 dan JMeter, Locust mendukung eksekusi terdistribusi secara bawaan: satu master-node mengoordinasikan beberapa worker-node. Eksekusi terdistribusi memungkinkan menghasilkan beban hingga 100000 RPS dari beberapa mesin. Locust juga mendukung pengujian WebSocket melalui ekstensi kustom.

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

Contoh Penulisan Load Test pada k6

Skrip k6 di atas menunjukkan struktur umum pengujian beban. Options menentukan profil beban: ramp-up 2 menit hingga 100 pengguna, kemudian 5 menit beban konstan dan ramp-up lagi hingga 200 pengguna. Thresholds menetapkan kriteria kelulusan pengujian: p95 waktu permintaan tidak lebih dari 500 ms, persentase kesalahan kurang dari 1%. Jika ambang dilampaui, k6 menyelesaikan pengujian dengan kode bukan nol — ini memungkinkan integrasi Load Test ke dalam CI/CD.

Dalam pengembangan mobile, Load Test sisi server sangat penting saat meluncurkan fitur baru yang menciptakan beban tambahan: like, komentar, streaming. Rekomendasi — lakukan Load Test di setiap staging sebelum peluncuran ke production. Pembuatan profil beban baseline pada tahap desain API membantu menghindari masalah arsitektur di tahap akhir.