Analisis Hasil & Menemukan Bottleneck Sebenarnya — Belajar k6

Urutan Analisis yang Benar

Jangan langsung menuduh database. Ikuti urutan ini agar tidak membuang waktu:

Validasi tesnya dulu. Apakah dropped_iterations = 0? Apakah CPU generator < 75%? Bila tidak, hasilnya belum layak dianalisis.
Lihat error rate. Bila > 5%, cari tahu jenis errornya sebelum melihat latency — latency dari sistem yang sedang error tidak bermakna.
Dekomposisi latency. blocked / connecting / waiting / receiving — bagian mana yang dominan?
Cari titik belok. Pada VU/RPS berapa latency mulai naik tajam? Itulah kapasitas efektif Anda.
Korelasikan dengan sisi server. Apa yang terjadi di CPU, memori, koneksi DB, dan GC pada detik yang sama?

Membaca Bentuk Grafik

Pola	Kemungkinan penyebab	Langkah verifikasi
Latency naik linear mengikuti VU	Sumber daya jenuh bertahap (CPU/koneksi)	Cek CPU & pool koneksi DB di server
Latency datar lalu meledak	Ada antrean yang penuh (thread pool, connection pool)	Cek ukuran pool & panjang antrean
Gigi gergaji (naik-turun berkala)	Garbage collection, cache expiry, atau cron job	Cek log GC & jadwal cron
Naik perlahan sepanjang tes tak pernah turun	Kebocoran: memori, koneksi, atau file descriptor	Soak test + pantau RSS/koneksi
Spike di awal lalu normal	Cold start: JIT, cache dingin, pool belum terisi	Normal — beri fase warm-up
Error muncul tepat di angka bulat (100 rps)	Rate limiter / kuota	Cek konfigurasi WAF, API gateway, LB

Bottleneck yang Paling Sering Ditemukan

Bottleneck	Gejala di k6	Perbaikan umum
N+1 query	`waiting` naik tajam seiring jumlah data	Eager loading / JOIN / batch query
Connection pool DB habis	Latency mendadak meledak di ambang tertentu	Naikkan pool, perpendek transaksi
Tidak ada index	Satu endpoint jauh lebih lambat dari lainnya	`EXPLAIN ANALYZE` lalu tambah index
Panggilan eksternal sinkron	`waiting` tinggi & stabil, CPU server rendah	Jadikan asinkron, tambah timeout & circuit breaker
Thread/worker pool kecil	Throughput mentok di angka tetap	Naikkan worker (gunicorn/pm2/uvicorn)
Logging berlebihan	CPU server tinggi, disk I/O jenuh	Turunkan level log, buat asinkron
Rate limiter	Banyak 429 pada laju tertentu	Allowlist IP generator saat pengujian

⛔ Jangan simpulkan bottleneck hanya dari data k6

k6 mengukur dari luar — ia hanya tahu request lambat, tetapi tidak tahu kenapa. Kesimpulan yang bisa dipercaya selalu lahir dari korelasi dua sisi:

Sisi klien (k6): latency, throughput, error rate.
Sisi server: CPU, memori, koneksi DB, slow query log, GC, panjang antrean.

Samakan sumbu waktunya, lalu cari apa yang berubah di server tepat saat latency melonjak. Tanpa ini Anda hanya menebak.

Menghitung Kapasitas Efektif

Setelah stress test, tentukan tiga angka yang akan dipakai untuk perencanaan kapasitas:

Titik jenuh — beban saat throughput berhenti naik meski VU ditambah.
Titik patah — beban saat error rate melewati ambang yang bisa diterima (misal 1%).
Kapasitas aman — biasanya 60–70% dari titik jenuh, sebagai ruang untuk lonjakan tak terduga.

Kerangka Laporan yang Dibaca Orang

laporan.mdmarkdown

# Laporan Load Test — Checkout API — 27 Juli 2026

## Kesimpulan (untuk yang tidak sempat baca semuanya)
Sistem sanggup 420 checkout/menit dengan p95 = 680 ms.
Target kampanye 600/menit BELUM terpenuhi.
Penyebab utama: connection pool PostgreSQL mentok di 20.
Perkiraan perbaikan: naikkan pool ke 60 -> estimasi kapasitas 900/menit.

## Ringkasan Angka
| Metrik              | Hasil   | Target  | Status |
|---------------------|---------|---------|--------|
| Throughput puncak   | 420/mnt | 600/mnt | GAGAL  |
| p95 latency         | 680 ms  | 800 ms  | LULUS  |
| p99 latency         | 3.2 s   | 2 s     | GAGAL  |
| Error rate          | 2.1%    | < 1%    | GAGAL  |

## Bukti
- Latency datar sampai 350/mnt, lalu meledak (pola antrean penuh).
- Log PostgreSQL: "remaining connection slots are reserved" pada 14:32:10.
- CPU aplikasi hanya 45% saat p99 melonjak -> bukan CPU-bound.

## Rekomendasi (urut prioritas)
1. Naikkan max_connections PostgreSQL 20 -> 60 dan pasang PgBouncer.  (Dampak besar, effort kecil)
2. Tambah index pada pesanan(user_id, dibuat_pada).                    (Dampak sedang)
3. Jadikan pengiriman email konfirmasi asinkron lewat queue.           (Dampak sedang, effort besar)

## Batasan Pengujian
- Dijalankan di staging (4 vCPU) — produksi memakai 16 vCPU.
- CDN dinonaktifkan, sehingga beban ke origin lebih berat dari kondisi nyata.