KodelokaMasalah yang Sebenarnya Kita Selesaikan
Aplikasi yang lancar dipakai 5 orang belum tentu bertahan saat dipakai 5.000 orang. Kegagalan performa hampir selalu muncul di waktu paling mahal: flash sale, pembukaan PPDB, awal bulan penggajian, atau saat kampanye marketing baru jalan. Load testing adalah cara kita memindahkan kegagalan itu dari produksi ke laptop kita sendiri, jauh sebelum pengguna merasakannya.
Load testing adalah proses menirukan perilaku sejumlah pengguna secara bersamaan terhadap sebuah sistem, lalu mengukur tiga hal: latency (berapa lama), throughput (berapa banyak per detik), dan error rate (berapa persen gagal) — pada level beban yang terdefinisi.
Enam Jenis Pengujian Performa
Ini adalah kosakata dasar. Salah menyebut jenis tes akan membuat hasilnya salah dibaca oleh tim lain.
| Jenis | Beban | Pertanyaan yang Dijawab | Durasi Khas |
|---|---|---|---|
| Smoke test | 1–5 VU | Apakah skripnya benar dan sistem tidak error di beban minimal? | 30 detik – 1 menit |
| Load test | Beban normal / rata-rata puncak | Apakah SLO terpenuhi pada beban sehari-hari? | 10 – 30 menit |
| Stress test | Naik bertahap melewati kapasitas | Di titik mana sistem mulai rusak? | 20 – 60 menit |
| Spike test | Lonjakan mendadak lalu turun | Apakah sistem selamat dan pulih setelah lonjakan? | 2 – 10 menit |
| Soak / endurance | Beban normal, waktu panjang | Adakah memory leak, koneksi bocor, disk penuh? | 2 – 24 jam |
| Breakpoint test | Naik terus tanpa batas sampai jebol | Berapa kapasitas maksimum absolut? | Sampai gagal |
Kenapa k6, Bukan JMeter?
k6 dibuat oleh Load Impact (kini bagian dari Grafana Labs). Inti mesinnya ditulis dengan Go — hemat memori dan sangat efisien — sementara skrip tesnya ditulis dengan JavaScript (ES6+) sehingga akrab bagi developer.
| Aspek | Apache JMeter | Grafana k6 |
|---|---|---|
| Definisi tes | XML lewat GUI (sulit di-review di Git) | File JavaScript (diff-able, code review biasa) |
| Model konkurensi | 1 thread OS per virtual user (berat) | Goroutine + JS VM ringan (ribuan VU di 1 mesin) |
| Konsumsi memori | Ratusan MB–GB, sering butuh tuning JVM | Umumnya ± 1–5 MB per VU |
| Integrasi CI/CD | Perlu plugin & konfigurasi tambahan | Satu binary, exit code non-zero saat threshold gagal |
| Kriteria lulus/gagal | Assertion terpisah, tidak baku | thresholds — SLO sebagai kode, kelas satu |
| Ekosistem observability | Terpisah | Native ke Prometheus, Grafana, Loki, Tempo |
- Bukan browser sungguhan (secara default). k6 mengirim HTTP request langsung — ia tidak menjalankan JavaScript halaman, tidak me-render CSS, tidak memuat gambar otomatis. Jadi k6 mengukur performa backend, bukan Core Web Vitals. Untuk itu ada modul
k6/browseryang dibahas di modul lanjutan. - Bukan alat monitoring. k6 menghasilkan beban dan mengukur dari sisi klien. Untuk tahu kenapa lambat, Anda tetap butuh Prometheus/Grafana di sisi server.
- Bukan pengganti unit test. k6 menguji perilaku sistem di bawah beban, bukan kebenaran logika bisnis.
Kosakata Wajib: SLI, SLO, SLA
Tiga istilah ini sering tertukar padahal beda tanggung jawab hukum dan teknisnya.
- SLI (Service Level Indicator) — angka yang diukur. Contoh:
p95 latency endpoint /checkout. - SLO (Service Level Objective) — target internal atas SLI. Contoh:
p95 < 500 ms selama 30 hari. Inilah yang kita terjemahkan menjadithresholdsdi k6. - SLA (Service Level Agreement) — janji kontraktual ke pelanggan, biasanya lebih longgar dari SLO dan ada denda bila dilanggar.
Bila belum ada SLO resmi, mulai dari data produksi Anda sendiri: ambil p95 latency saat ini, tetapkan sebagai batas maksimum agar tidak terjadi regresi, lalu perketat bertahap. Menetapkan target dari angan-angan ("pokoknya di bawah 100 ms") hanya menghasilkan pipeline merah yang akhirnya diabaikan tim.
Kenapa p95, Bukan Rata-rata?
Rata-rata (average) menyembunyikan penderitaan. Bila 95 request selesai 50 ms dan 5 request selesai 5.000 ms, rata-ratanya 297 ms — terlihat sehat, padahal 5% pengguna Anda menunggu 5 detik. Persentil menjawab pertanyaan yang benar:
- p50 (median) — pengalaman pengguna tipikal.
- p95 — pengalaman 5% pengguna paling apes. Ini metrik utama untuk SLO.
- p99 — ekor terburuk, biasanya mengungkap masalah GC, lock database, atau cold start.