Test Banyak User untuk Menguji Batas Maksimal Website Anda

Sebagian besar pemilik sistem berasumsi bahwa website mereka siap menghadapi lonjakan traffic hanya karena server memiliki spesifikasi tinggi. Kenyataannya, infrastruktur termahal sekalipun bisa runtuh akibat konfigurasi database yang buruk atau memory leak pada aplikasi. Untuk membuktikan ketahanan sistem, Anda tidak bisa sekadar berasumsi—Anda harus menyerangnya secara terkontrol.

Di sinilah Grafana k6 berperan. k6 adalah tool load testing open-source berbasis skrip JavaScript yang dirancang oleh developer untuk membanjiri aplikasi Anda dengan ribuan Virtual Users (VU) guna menemukan titik hancurnya (breaking point).

Artikel ini akan memandu Anda dari proses instalasi hingga eksekusi pengujian pertama.

1. Instalasi k6

k6 ditulis menggunakan bahasa Go dan didistribusikan sebagai sebuah file biner tunggal, sehingga sangat ringan dan mudah diinstal di berbagai sistem operasi.

• Mac (Homebrew):

  brew install k6

• Windows (Winget):

  winget install k6

• Linux (Debian/Ubuntu):

  sudo gpg -k
  sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
  echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
  sudo apt-get update
  sudo apt-get install k6

2. Membuat Skrip Pengujian Pertama Anda

Tidak seperti Apache JMeter yang bergantung pada GUI berbasis XML yang berat, k6 menggunakan JavaScript murni. Hal ini memungkinkan Anda menyimpan skrip pengujian di dalam sistem version control (seperti Git) bersama dengan kode aplikasi Anda.

Buat sebuah file bernama script.js dan tempelkan kode berikut:

import http from 'k6/http';
import { sleep, check } from 'k6';

// Konfigurasi skenario pengujian
export let options = {
    vus: 50,           // Mensimulasikan 50 Virtual Users berjalan bersamaan
    duration: '30s',   // Pengujian akan berlangsung selama 30 detik
};

// Fungsi utama yang akan dieksekusi oleh setiap Virtual User
export default function () {
    // Ganti URL dengan endpoint yang ingin Anda uji
    let res = http.get('https://test-api.k6.io/public/crocodiles/');
    
    // Validasi bahwa respons server adalah 200 OK
    check(res, {
        'status is 200': (r) => r.status === 200,
        'transaction time OK': (r) => r.timings.duration < 500, // Harus di bawah 500ms
    });

    // Jeda simulasi waktu baca user (Think Time)
    sleep(1);
}

3. Mengeksekusi Pengujian

Buka terminal di direktori tempat Anda menyimpan script.js dan jalankan perintah:

k6 run script.js

Anda akan melihat logo k6 di terminal, diikuti dengan bilah progres eksekusi.

4. Membaca Hasil Metrik (dan Mengapa Anda Mungkin Salah Menilainya)

Setelah 30 detik, k6 akan mencetak laporan metrik. Beberapa metrik terpenting meliputi:

• http_reqs: Total permintaan HTTP yang berhasil dikirim k6.
• http_req_duration: Waktu total dari pengiriman request hingga menerima response. Perhatikan nilai p(95) (persentil ke-95) yang menunjukkan durasi mayoritas request, bukan hanya nilai rata-rata (avg).
• http_req_failed: Persentase request yang gagal.

Sudut Pandang Kritis: Asumsi Berbahaya dalam Load Testing

Banyak tim engineering merasa puas ketika hasil k6 menunjukkan http_req_failed: 0.00% dengan 1.000 Virtual Users. Saya harus menantang asumsi ini: Lolos load testing di k6 tidak berarti sistem Anda aman di dunia nyata.

1. Akses Konkuren ≠ Perilaku Manusia: Skrip sederhana yang memukul satu endpoint secara berulang (GET /homepage) adalah simulasi bodoh. Pengguna asli melakukan login, memuat aset statis, mencari produk, dan meninggalkan keranjang belanja secara sporadis. Jika skrip Anda tidak meniru Customer Journey yang kompleks, hasil k6 Anda memberikan rasa aman yang palsu (false sense of security).
2. Titik Buta (Blind Spot) Backend: k6 adalah alat ukur eksternal. K6 mungkin melaporkan durasi permintaan yang cepat, namun di balik layar, CPU server database Anda mungkin sudah berada di angka 99% dan berada di ambang kerusakan. Melakukan load testing tanpa menghubungkannya dengan Application Performance Monitoring (APM) seperti Datadog, New Relic, atau Prometheus adalah kelalaian yang fatal.
3. Masalah Data Caching: Jika Anda menguji endpoint dengan satu set data yang sama berulang-ulang, sistem Anda mungkin hanya melayani data tersebut langsung dari Cache (seperti Redis), bukan benar-benar memprosesnya dari database. Begitu sistem live, cache miss dari pengguna yang memasukkan kueri berbeda akan melumpuhkan performa aplikasi dalam hitungan detik.

Kesimpulan Eksekusi: Gunakan k6 bukan hanya untuk melihat berapa angka maksimal yang bisa dicapai aplikasi Anda, tetapi gunakan untuk menemukan di bagian mana aplikasi tersebut pada akhirnya rusak.