Testing 1: Load and performance testing

Load and performance testing dengan K6

Jenis-Jenis Uji Beban (Load Test)

Banyak hal yang bisa salah ketika sebuah sistem berada di traffik yang tinggi. Sistem harus menjalankan banyak operasi secara bersamaan dan merespons berbagai permintaan dari sejumlah pengguna yang bervariasi (concurrent users). Untuk mengantisipasi risiko kinerja ini, kita bisa menggunakan uji beban (load testing). Namun, strategi uji beban yang baik tidak cukup hanya dengan menjalankan satu skrip saja. Pola trafik yang berbeda menciptakan profil risiko (risk profiles) yang berbeda bagi aplikasi. Untuk persiapan yang lebih menyeluruh, kita harus menguji sistem dengan berbagai jenis pengujian.

Bentuk-Bentuk Uji Beban

Uji Berbeda untuk Tujuan Berbeda

Mulailah dengan smoke test, lalu tingkatkan beban dan durasi secara bertahap.

Berikut adalah jenis-jenis utama uji beban. Setiap jenis memiliki konsep dan tujuan spesifiknya:

• Smoke Test: Memvalidasi apakah skrip pengujian berfungsi dan apakah sistem dapat bekerja dengan baik di bawah beban minimal.

• Uji Beban Normal (Average Load Test): Mengevaluasi bagaimana sistem bekerja dalam kondisi penggunaan yang diharapkan.

• Uji Stres (Stress Test): Mengevaluasi kinerja sistem pada batas maksimumnya ketika beban melebihi rata-rata yang diharapkan.

• Uji Ketahanan (Soak Test): Mengukur keandalan dan kinerja sistem dalam jangka waktu yang panjang.

• Uji Lonjakan (Spike Test): Memverifikasi bagaimana sistem berperilaku dan bertahan dalam lonjakan aktivitas yang tiba-tiba, singkat, dan besar.

• Uji Batas (Breakpoint Test): Meningkatkan beban secara bertahap untuk mengidentifikasi kapasitas maksimum sistem.

Catatan

Dalam skrip k6, konfigurasi beban dapat diatur menggunakan opsi atau skenario. Ini memungkinkan pemisahan antara konfigurasi beban kerja dan logika iterasi.

Ringkasan Jenis Uji Beban

Jenis Uji	Virtual Users (VU) / Throughput	Durasi	Kapan Digunakan?
Smoke	Rendah	Pendek (detik atau menit)	Saat ada perubahan kode sistem atau aplikasi untuk memeriksa logika fungsional, metrik dasar, dan penyimpangan
Load	Rata-rata produksi	Menengah (5-60 menit)	Sering digunakan untuk memastikan sistem dapat mempertahankan kinerjanya dalam penggunaan rata-rata
Stress	Tinggi (di atas rata-rata)	Menengah (5-60 menit)	Ketika sistem diperkirakan menerima beban di atas rata-rata untuk menguji bagaimana sistem menangani kondisi tersebut
Soak	Rata-rata	Panjang (berjam-jam)	Setelah ada perubahan untuk menguji kinerja sistem dalam penggunaan terus-menerus yang berkepanjangan
Spike	Sangat tinggi	Pendek (beberapa menit)	Saat sistem dipersiapkan untuk acara musiman atau sering menerima lonjakan lalu lintas
Breakpoint	Meningkat sampai batasnya	Selama yang diperlukan	Dilakukan beberapa kali untuk menemukan batas maksimum sistem

Rekomendasi Umum

Mulailah dengan Uji Asap

Sebelum menjalankan pengujian yang lebih besar, pastikan terlebih dahulu bahwa skrip berfungsi sebagaimana mestinya dan sistem dapat bekerja dengan baik dengan sejumlah kecil pengguna. Setelah itu, lanjutkan ke pengujian beban rata-rata, lalu ke pola beban yang lebih kompleks.

Sesuaikan dengan Kasus Penggunaan

Setiap sistem memiliki arsitektur dan basis pengguna yang berbeda, sehingga strategi uji beban yang tepat sangat bergantung pada profil risiko organisasi. Hindari berpikir dalam konsep yang absolut.

Sebagai contoh, k6 dapat memodelkan beban berdasarkan jumlah Virtual Users (VU) atau jumlah iterasi per detik (sistem terbuka vs. tertutup). Saat merancang pengujian, pertimbangkan pola mana yang paling sesuai dengan kebutuhan.

Selain itu, tidak ada satu jenis pengujian yang dapat menghilangkan semua risiko. Untuk mengevaluasi berbagai kemungkinan kegagalan dalam sistem, gunakan kombinasi dari beberapa jenis pengujian. Profil risiko sistem akan menentukan jenis pengujian mana yang harus lebih diprioritaskan:

• Jika sistem lebih rentan terhadap penggunaan jangka panjang, uji ketahanan (soak test) harus diutamakan.

• Jika sistem lebih rentan terhadap penggunaan intensif, uji stres (stress test) harus menjadi prioritas utama.

Gunakan Desain yang Sederhana dan Hasil yang Dapat Direproduksi

Meskipun detail pengujian sangat bergantung pada konteksnya, prinsip utamanya adalah menghasilkan hasil yang dapat dibandingkan dan diinterpretasikan dengan mudah.

• Gunakan pola beban yang sederhana, yaitu: peningkatan bertahap, dataran tinggi (plateau), dan penurunan bertahap.

• Hindari pola seperti "rollercoaster", di mana beban naik dan turun berkali-kali, karena ini akan menghabiskan sumber daya dan menyulitkan analisis penyebab masalah.

Dengan strategi yang tepat, uji beban dapat membantu memastikan sistem dapat bekerja dengan optimal di berbagai skenario penggunaan.

Smoke Testing

Pengertian Smoke Test

Smoke test dilakukan dengan beban minimal. Bentuk ini digunakan untuk memverifikasi apakah sistem dapat berjalan dengan baik dalam kondisi beban rendah serta untuk mengumpulkan nilai dasar kinerja.

Jenis pengujian ini dijalankan dengan beberapa Virtual Users (VU). Lebih dari 5 VU dapat dianggap sebagai pengujian mini-load.

Selain itu, smoke test hanya dieksekusi dalam waktu singkat, baik dengan jumlah iterasi rendah atau durasi beberapa detik hingga maksimal beberapa menit.

Gambaran Umum Smoke Test

Dalam beberapa diskusi mengenai pengujian, smoke test juga disebut sebagai shakeout test.

Kapan Smoke Test Dijalankan?

Tim harus menjalankan smoke test setiap kali skrip pengujian dibuat atau diperbarui. Smoke testing juga harus dilakukan setiap kali kode aplikasi yang relevan mengalami perubahan.

Disarankan untuk menjadikan smoke test sebagai langkah awal dengan tujuan sebagai berikut:

• Memastikan bahwa skrip pengujian tidak memiliki kesalahan.

• Memverifikasi bahwa sistem tidak mengalami error (baik yang terkait dengan performa maupun sistem) saat berada di bawah beban minimal.

• Mengumpulkan metrik performa dasar dari respons sistem di bawah beban minimal.

• Dengan logika sederhana, smoke test dapat berfungsi sebagai pengujian sintetis untuk memantau performa dan ketersediaan lingkungan produksi.

Hal yang Perlu Dipertimbangkan

Saat mempersiapkan smoke test, perhatikan beberapa hal berikut:

Jalankan Smoke Test Setiap Kali Skrip Dibuat atau Diperbarui

Karena smoke test digunakan untuk memverifikasi skrip pengujian, usahakan menjalankannya setiap kali Anda membuat atau memperbarui skrip. Hindari menjalankan jenis pengujian lain dengan skrip yang belum diuji.

Gunakan Throughput Kecil dan Durasi Singkat

Konfigurasikan skrip pengujian agar dijalankan oleh sejumlah kecil VU (antara 2 hingga 20) dengan sedikit iterasi atau durasi singkat (30 detik hingga 3 menit).

Smoke Testing dengan k6

Berikut adalah contoh skrip smoke test menggunakan k6:

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

export const options = {
  vus: 3, // Untuk Smoke Test, sebaiknya antara 2 hingga maksimal 5 VU
  duration: '1m', // Bisa lebih pendek atau hanya beberapa iterasi
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // LANGKAH TAMBAHAN
  // Anda bisa menambahkan langkah atau logika lebih kompleks
  // Langkah1
  // Langkah2
  // dst.
};

Skrip di atas adalah contoh smoke test. Anda bisa menyalinnya, mengubah endpoint, dan langsung melakukan pengujian. Untuk logika pengujian yang lebih komprehensif, lihat contoh lainnya dalam dokumentasi k6.

Diagram berikut menunjukkan bentuk smoke test yang dikonfigurasi berdasarkan skrip di atas.

Analisis Hasil

Smoke test awalnya digunakan untuk memastikan bahwa skrip Anda dapat berjalan tanpa error. Jika terdapat error dalam skrip, perbaiki terlebih dahulu sebelum menjalankan pengujian lebih lanjut.

Di sisi lain, jika Anda menemukan performa buruk meskipun menggunakan jumlah VU yang rendah, laporkan masalah tersebut, perbaiki lingkungan pengujian, lalu coba lagi dengan smoke test sebelum menjalankan pengujian lainnya.

Setelah smoke test menunjukkan nol error dan hasil performa tampak dapat diterima, Anda bisa melanjutkan ke jenis pengujian lainnya.

Pengujian Beban Rata-Rata (Average-Load Testing)

Pengertian Pengujian Beban Rata-Rata

Pengujian beban rata-rata bertujuan untuk menilai bagaimana sistem bekerja di bawah beban tipikal. Beban tipikal ini mencerminkan kondisi normal sehari-hari dalam produksi.

Pengujian ini mensimulasikan jumlah pengguna bersamaan dan permintaan per detik yang mencerminkan rata-rata perilaku dalam lingkungan produksi. Biasanya, throughput atau jumlah VU ditingkatkan secara bertahap dan dipertahankan dalam jangka waktu tertentu. Bergantung pada karakteristik sistem, pengujian dapat dihentikan secara tiba-tiba atau memiliki periode penurunan beban (ramp-down) yang singkat.

Gambaran Umum Pengujian Beban Rata-Rata

Karena istilah "load test" dapat merujuk pada berbagai jenis pengujian lalu lintas, dalam panduan ini digunakan istilah "average-load test" untuk menghindari kebingungan. Dalam beberapa diskusi, pengujian ini juga disebut "day-in-life test" atau "volume test".

Kapan Pengujian Beban Rata-Rata Dijalankan?

Pengujian ini membantu memahami apakah sistem memenuhi tujuan performa dalam kondisi beban sehari-hari (beban umum). Beban sehari-hari berarti ketika sejumlah rata-rata pengguna mengakses aplikasi secara bersamaan dan melakukan aktivitas normal.

Anda sebaiknya menjalankan pengujian ini untuk:

• Menilai performa sistem di bawah beban tipikal.

• Mengidentifikasi tanda-tanda degradasi awal selama periode peningkatan atau beban penuh.

• Memastikan bahwa sistem tetap memenuhi standar performa setelah ada perubahan kode atau infrastruktur.

Hal yang Perlu Dipertimbangkan

Saat mempersiapkan pengujian beban rata-rata, pertimbangkan beberapa hal berikut:

Ketahui Jumlah Pengguna dan Throughput Tipikal

Gunakan alat pemantauan aplikasi (APM) atau analitik yang menyediakan informasi dari lingkungan produksi. Jika tidak tersedia, estimasi dari pihak bisnis dapat digunakan.

Tingkatkan Beban Secara Bertahap

Gunakan periode peningkatan beban (ramp-up) sekitar 5% hingga 15% dari total durasi pengujian untuk:

• Memberi waktu sistem untuk menyesuaikan diri atau melakukan auto-scale.

• Membandingkan waktu respons antara tahap beban rendah dan rata-rata.

• Mengoptimalkan peringatan otomatis dalam pengujian cloud.

Pertahankan Beban Rata-Rata Lebih Lama dari Ramp-Up

Usahakan durasi beban rata-rata setidaknya lima kali lebih lama dari ramp-up untuk menilai tren performa secara signifikan.

Pertimbangkan Periode Ramp-Down

Periode ramp-down adalah saat aktivitas pengguna virtual berkurang secara bertahap, biasanya berlangsung selama atau sedikit lebih singkat dari ramp-up.

Pengujian Beban Rata-Rata dengan k6

Berikut adalah contoh skrip pengujian beban rata-rata:

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

export const options = {
  stages: [
    { duration: '5m', target: 100 }, // Peningkatan lalu lintas dari 1 ke 100 pengguna dalam 5 menit
    { duration: '30m', target: 100 }, // Bertahan di 100 pengguna selama 30 menit
    { duration: '5m', target: 0 }, // Menurunkan beban ke 0 pengguna
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
};

Analisis Hasil

Hasil awal muncul selama ramp-up untuk melihat apakah waktu respons memburuk seiring peningkatan beban. Jika sistem mengalami penurunan performa, perbaiki sebelum melanjutkan ke pengujian lebih lanjut.

Stress Testing

Pengertian Stress Testing

Stress testing menilai bagaimana sistem berperforma ketika beban yang diberikan lebih tinggi dari biasanya.

Polanya mirip dengan pengujian beban rata-rata (average-load test), tetapi dengan tingkat beban yang lebih besar. Untuk mengakomodasi beban ini, periode ramp-up (peningkatan beban secara bertahap) berlangsung lebih lama. Setelah mencapai beban yang diinginkan, pengujian mungkin berlangsung sedikit lebih lama dibandingkan dengan pengujian beban rata-rata.

Gambaran Umum Stress Test

Dalam beberapa diskusi mengenai pengujian perangkat lunak, stress test juga disebut sebagai rush-hour test, surge test, atau scale test.

Kapan Stress Test Dilakukan?

Stress test digunakan untuk memverifikasi stabilitas dan keandalan sistem dalam kondisi penggunaan berat. Sistem dapat mengalami lonjakan beban yang tidak biasa pada saat-saat tertentu, seperti:

• Tenggat waktu suatu proses

• Hari gajian

• Jam sibuk

• Akhir pekan

• Pola perilaku lain yang menyebabkan lonjakan lalu lintas di atas rata-rata

Hal yang Perlu Dipertimbangkan

1. Beban Harus Lebih Tinggi dari Rata-Rata

Beban dalam stress test harus lebih tinggi dari yang biasa dialami sistem dalam kondisi normal.

2. Tidak Ada Persentase Tetap untuk Stress Test

Beberapa penguji mungkin menggunakan target default, misalnya peningkatan 50% hingga 100% dari beban rata-rata, tetapi tidak ada standar tetap.

Beban yang digunakan bergantung pada kondisi ekstrem yang mungkin dialami sistem. Kadang-kadang hanya sedikit lebih tinggi dari rata-rata, tetapi dalam beberapa kasus, bisa meningkat dua kali lipat, tiga kali lipat, atau bahkan lebih besar lagi.

3. Tentukan Beban Berdasarkan Pola Risiko

Tentukan beban berdasarkan pola risiko yang mungkin dialami sistem dalam kondisi penggunaan ekstrem.

4. Jalankan Stress Test Setelah Average-Load Test

Identifikasi terlebih dahulu masalah performa dalam pengujian beban rata-rata sebelum mencoba pengujian yang lebih berat. Urutan ini sangat penting agar tidak menguji sistem dengan beban ekstrem sebelum mengetahui batas normalnya.

5. Gunakan Skrip Average-Load Test dengan Modifikasi

Gunakan kembali skrip pengujian beban rata-rata, tetapi ubah parameternya untuk meningkatkan jumlah VU atau beban yang lebih tinggi.

6. Harapkan Performa Menurun

Stress test bertujuan untuk mengukur sejauh mana performa sistem menurun ketika beban meningkat. Sistem yang baik harus mampu mempertahankan response time yang konsisten meskipun berada dalam beban tinggi untuk waktu yang lama.

Stress Testing dengan k6

Beban dalam stress test mirip dengan pengujian beban rata-rata, tetapi dengan tingkat beban yang lebih tinggi.

1. Tingkatkan aktivitas skrip secara bertahap dengan ramp-up yang lebih lambat hingga mencapai jumlah pengguna atau throughput di atas rata-rata.

2. Pertahankan beban tinggi selama beberapa waktu.

3. Turunkan beban secara perlahan (ramp-down) atau hentikan pengujian tergantung pada skenario pengujian.

Berikut contoh skrip k6 untuk stress test:

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

export const options = {
  // Konfigurasi utama untuk Stress Test
  stages: [
    { duration: '10m', target: 200 }, // Ramp-up: dari 1 ke 200 pengguna dalam 10 menit
    { duration: '30m', target: 200 }, // Beban tinggi: tetap di 200 pengguna selama 30 menit
    { duration: '5m', target: 0 }, // Ramp-down: menurunkan pengguna menjadi 0
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // Tambahkan langkah tambahan jika diperlukan
  // Langkah1
  // Langkah2
  // dst.
};

Bentuk Grafik Stress Test

Kurva pengguna virtual (VU) atau throughput dalam stress test terlihat serupa dengan average-load test, tetapi dengan tingkat beban yang lebih tinggi.

Pengujian dimulai dari 0, lalu meningkat hingga melampaui titik yang diuji dalam average-load test. Periode ramp-up dan ramp-down lebih panjang untuk mendapatkan respons yang lebih realistis.

Catatan Penting

• Jalankan stress test hanya setelah smoke test dan average-load test.

• Menjalankan stress test terlalu dini bisa menghabiskan sumber daya secara tidak perlu dan membuat sulit mengidentifikasi masalah yang mungkin sudah muncul pada tingkat beban lebih rendah.

Analisis Hasil Stress Test

Mirip dengan average-load test, hasil awal dari stress test bisa diamati selama periode ramp-up. Jika waktu respons mulai menurun drastis seiring peningkatan beban, itu bisa menjadi indikasi potensi bottleneck pada sistem.

Pada periode full load, pastikan bahwa konsumsi sumber daya tetap stabil dan sistem tidak mengalami crash atau degradasi performa yang tidak terkendali.

Jika sistem berhasil menangani beban tinggi dalam stress test, langkah berikutnya adalah melakukan Soak Test untuk melihat bagaimana performa sistem dalam jangka waktu panjang.

Soak Testing

Soak testing adalah variasi lain dari uji Average-Load. Fokusnya adalah pada periode yang lebih panjang, dengan menganalisis hal-hal berikut:

• Penurunan kinerja dan konsumsi sumber daya sistem selama periode yang panjang.

• Ketersediaan dan stabilitas sistem selama periode yang panjang.

Uji soak berbeda dari uji average-load dalam durasi uji. Dalam uji soak, durasi beban puncak (biasanya dalam jumlah rata-rata) berlangsung selama beberapa jam atau bahkan hari. Meskipun durasinya jauh lebih lama, periode ramp-up dan ramp-down pada uji soak sama seperti pada uji average-load.

Gambaran Umum Soak Test

Dalam beberapa percakapan tentang pengujian, uji soak mungkin disebut sebagai endurance test, constant high load test, atau stamina test.

Kapan Melakukan Soak Test

Sebagian besar sistem harus tetap menyala dan terus bekerja selama hari, minggu, dan bulan tanpa intervensi. Uji ini memverifikasi stabilitas dan keandalan sistem selama penggunaan yang panjang.

Jenis uji ini memeriksa cacat kinerja umum yang hanya muncul setelah penggunaan yang lama, seperti penurunan waktu respons, kebocoran memori atau sumber daya lainnya, saturasi data, dan kehabisan penyimpanan.

Pertimbangan

Saat mempersiapkan untuk menjalankan uji soak, pertimbangkan hal-hal berikut:

• Konfigurasikan durasi uji agar jauh lebih lama dari uji lainnya.

• Beberapa nilai umum adalah 3, 4, 8, 12, 24, dan 48 hingga 72 jam.

• Jika memungkinkan, gunakan kembali skrip uji average-load dan hanya ubah durasi puncaknya dengan nilai-nilai yang telah disebutkan.

• Jangan jalankan uji soak sebelum melakukan uji smoke dan average-load.

• Setiap uji mengungkapkan masalah yang berbeda. Menjalankan ini terlebih dahulu bisa menyebabkan kebingungan dan pemborosan sumber daya.

• Monitor sumber daya backend dan efisiensi kode. Karena kita memeriksa penurunan sistem, sangat disarankan untuk memonitor sumber daya backend dan efisiensi kode. Dari semua jenis uji, pemantauan backend sangat penting untuk uji soak.

Soak Testing di k6

Uji soak hampir sama dengan uji average-load. Perbedaannya hanya pada durasi puncak beban yang lebih lama.

Langkah-langkah untuk uji soak di k6:

1. Tingkatkan beban hingga mencapai jumlah pengguna atau throughput rata-rata.

2. Pertahankan beban itu untuk waktu yang jauh lebih lama.

3. Terakhir, tergantung pada kasus uji, berhenti atau turunkan beban secara bertahap.

Konfigurasi durasi beban dalam objek opsi:

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

export const options = {
  // Konfigurasi utama untuk uji soak pada bagian ini
  stages: [
    { duration: '5m', target: 100 }, // peningkatan lalu lintas dari 1 ke 100 pengguna selama 5 menit.
    { duration: '8h', target: 100 }, // bertahan di 100 pengguna selama 8 jam!!!
    { duration: '5m', target: 0 }, // penurunan ke 0 pengguna
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // LANGKAH-LANGKAH LAIN
  // Di sini Anda bisa menambahkan langkah lebih lanjut atau skrip yang lebih kompleks
  // Langkah1
  // Langkah2
  // dll.
};

Untuk perilaku yang lebih kompleks, lihat contoh lainnya.

Perhatikan bahwa, seperti pada uji average-load, puncak beban mencapai 100 VUs. Perbedaannya ada pada durasi. Pada uji soak ini, puncak beban dipertahankan selama 8 jam, bukan hanya beberapa menit.

Analisis Hasil

Jika kita menjalankan uji ini setelah jenis uji sebelumnya, seharusnya sistem kita berfungsi dengan baik pada skenario-skenario sebelumnya. Dalam uji ini, pantau perubahan pada metrik kinerja seiring berjalannya waktu. Cobalah untuk menghubungkan dampak apa pun dengan perubahan pengukuran backend yang menunjukkan penurunan seiring waktu. Perubahan ini bisa berupa penurunan bertahap, seperti yang disebutkan, dan perubahan mendadak (termasuk peningkatan) dalam waktu respons dan sumber daya perangkat keras backend. Sumber daya backend yang perlu diperiksa adalah RAM yang digunakan, CPU, jaringan, dan pertumbuhan sumber daya cloud, antara lain.

Hasil yang diharapkan adalah bahwa kinerja dan pemanfaatan sumber daya backend tetap stabil atau berada dalam variasi yang diharapkan.

Setelah Anda menjalankan semua jenis uji sebelumnya, Anda akan tahu bahwa sistem Anda berfungsi dengan baik pada berbagai beban: rendah, rata-rata, tinggi, dan diperpanjang.

Spike Testing

Spike testing memverifikasi apakah sistem dapat bertahan dan berfungsi dengan baik di bawah lonjakan penggunaan yang mendadak dan besar.

Uji spike berguna ketika sistem berpotensi mengalami lonjakan lalu lintas yang mendadak dan besar. Contoh peristiwa seperti itu termasuk penjualan tiket (misalnya Taylor Swift), peluncuran produk (misalnya PS5), iklan siaran (misalnya Super Bowl), tenggat waktu proses (misalnya deklarasi pajak), dan penjualan musiman (misalnya Black Friday). Selain itu, lonjakan lalu lintas juga bisa disebabkan oleh peristiwa yang lebih sering terjadi seperti jam sibuk, tugas tertentu, atau kasus penggunaan tertentu.

Spike testing meningkatkan beban hingga tingkat yang sangat tinggi dalam waktu yang sangat singkat atau tanpa periode peningkatan yang signifikan. Biasanya, tidak ada periode dataran tinggi (plateau) atau sangat singkat, karena pengguna nyata umumnya tidak akan terus melakukan langkah-langkah tambahan dalam situasi ini. Demikian juga, periode penurunan beban (ramp-down) sangat cepat atau tidak ada, sehingga proses hanya terjadi sekali.

Uji ini mungkin melibatkan proses yang berbeda dari jenis pengujian sebelumnya, karena lonjakan sering kali bukan bagian dari aktivitas rata-rata di produksi. Uji ini juga bisa memerlukan penambahan, penghapusan, atau modifikasi proses dalam skrip yang tidak ada dalam uji average-load.

Terkadang, tim harus memperbarui sistem untuk memungkinkan atau memprioritaskan sumber daya bagi proses-proses yang permintaannya tinggi selama peristiwa tersebut.

Gambaran Umum Spike Test

Kapan Melakukan Spike Test

Uji ini harus dilakukan ketika sistem diperkirakan akan menerima lonjakan aktivitas mendadak.

Ketika sistem mengharapkan perilaku jenis ini, spike test membantu untuk mengidentifikasi bagaimana sistem akan berperilaku dan apakah sistem akan bertahan dari lonjakan beban yang mendadak tersebut. Beban pada uji spike ini jauh lebih tinggi dari rata-rata dan mungkin akan fokus pada proses yang berbeda dibandingkan dengan jenis uji lainnya.

Pertimbangan

Saat mempersiapkan untuk melakukan spike test, pertimbangkan hal-hal berikut:

• Fokus pada proses-proses kunci dalam jenis uji ini.

• Evaluasi apakah lonjakan lalu lintas memicu proses yang sama atau berbeda dibandingkan dengan jenis uji lainnya. Sesuaikan logika uji sesuai dengan itu.

• Uji ini sering kali tidak akan selesai.

• Kesalahan umum terjadi dalam skenario ini.

• Lakukan, sesuaikan, ulangi.

Ketika sistem Anda berisiko menghadapi peristiwa spike, tim harus menjalankan uji spike dan menyesuaikan sistem beberapa kali.

• Monitor.

Pemantauan backend adalah suatu keharusan untuk hasil uji ini yang sukses.

Spike Testing di k6

Perbedaan utama dari spike test adalah simulasi lonjakan beban yang mendadak dan sangat tinggi. Uji ini tidak memiliki durasi dataran tinggi (full load) atau biasanya sangat singkat.

Terkadang, uji ini memerlukan durasi dataran tinggi untuk beberapa saat. Jika diperlukan, durasi tersebut umumnya pendek. Periode penurunan beban (ramp-down) juga bisa cepat atau tidak diperlukan karena tujuan utamanya adalah untuk mendadak meningkatkan beban pada sistem.

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

export const options = {
  // Konfigurasi utama untuk spike test pada bagian ini
  stages: [
    { duration: '2m', target: 2000 }, // peningkatan cepat ke titik tinggi
    // Tanpa plateau
    { duration: '1m', target: 0 }, // penurunan cepat ke 0 pengguna
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // LANGKAH-LANGKAH LAIN
  // Tambahkan hanya proses yang akan mengalami permintaan tinggi
  // Langkah1
  // Langkah2
  // dll.
};

Pada uji spike, beban cepat meningkat ke level ekstrem. Periode penurunan beban mengikuti setelah uji mencapai maksimum, kembali ke 0 dengan cepat.

Uji spike mendapatkan namanya dari bentuk grafis beban yang ditunjukkan.

Analisis Hasil

Beberapa metrik kinerja yang perlu dievaluasi pada spike test termasuk kecepatan pod, waktu pemulihan setelah lonjakan beban, waktu untuk kembali ke normal, atau perilaku pada proses-proses penting sistem selama kelebihan beban.

Menemukan bagaimana sistem merespons (apakah bertahan) terhadap lonjakan mendadak membantu untuk mengoptimalkan sistem agar dapat bertahan selama peristiwa nyata. Pada beberapa peristiwa, beban bisa sangat tinggi sehingga seluruh sistem harus dioptimalkan untuk menangani proses-proses utama. Pada kasus-kasus seperti ini, ulangi uji hingga tingkat kepercayaan sistem tinggi.

Breakpoint Testing

Breakpoint testing bertujuan untuk menemukan batasan sistem. Beberapa alasan mengapa Anda mungkin ingin mengetahui batasan tersebut meliputi:

• Untuk menyesuaikan atau merawat titik lemah sistem dan memindahkan batas-batas tersebut ke level yang lebih tinggi.

• Untuk membantu merencanakan langkah-langkah perbaikan ketika sistem mendekati batas tersebut.

Dengan kata lain, mengetahui di mana dan bagaimana sistem mulai gagal membantu mempersiapkan diri menghadapi batasan tersebut.

Uji breakpoint meningkatkan beban hingga angka yang sangat tinggi secara tidak realistis. Uji ini umumnya harus dihentikan secara manual atau otomatis ketika ambang batas mulai gagal. Ketika masalah ini muncul, sistem telah mencapai batasnya.

Gambaran Umum Uji Breakpoint

Uji breakpoint adalah jenis pengujian lain yang tidak memiliki konsensus penamaan yang jelas. Dalam beberapa diskusi pengujian, ini juga dikenal sebagai pengujian kapasitas, titik beban, atau pengujian batas.

Kapan Melakukan Uji Breakpoint

Tim melakukan uji breakpoint kapan pun mereka perlu mengetahui batasan sistem mereka. Beberapa kondisi yang mungkin memerlukan uji breakpoint meliputi:

• Kebutuhan untuk mengetahui apakah beban sistem akan terus tumbuh.

• Jika konsumsi sumber daya saat ini dianggap tinggi.

• Setelah perubahan signifikan pada kode sumber atau infrastruktur.

Seberapa sering uji jenis ini dilakukan tergantung pada risiko mencapai batasan sistem dan jumlah perubahan untuk penyediaan komponen infrastruktur.

Setelah uji breakpoint dilakukan dan batasan sistem telah diidentifikasi, Anda dapat mengulang uji tersebut setelah melakukan penyesuaian untuk memvalidasi bagaimana hal itu memengaruhi batasan. Ulangi siklus uji-penyesuaian sampai tim puas dengan hasilnya.

Pertimbangan

• Hindari uji breakpoint di lingkungan cloud elastis.

Lingkungan elastis dapat berkembang seiring berjalannya uji, hanya menemukan batas dari tagihan akun cloud Anda. Jika uji ini dilakukan di lingkungan cloud, sangat disarankan untuk mematikan elastisitas di semua komponen yang terpengaruh.

• Tingkatkan beban secara bertahap.

Peningkatan yang mendadak dapat menyulitkan untuk menentukan alasan dan waktu kapan sistem mulai gagal.

• Kegagalan sistem dapat memiliki arti yang berbeda bagi tim yang berbeda.

Anda mungkin ingin mengidentifikasi masing-masing titik kegagalan berikut:

• Kinerja menurun. Waktu respons meningkat dan pengalaman pengguna menurun.

• Kinerja bermasalah. Waktu respons mencapai titik di mana pengalaman pengguna sangat terganggu.

• Timeout. Proses gagal karena waktu respons yang sangat tinggi.

• Kesalahan. Sistem mulai merespons dengan kode kesalahan HTTP.

• Kegagalan sistem. Sistem mengalami keruntuhan.

Anda dapat mengulang uji ini beberapa kali.

Mengulang setelah setiap penyesuaian memungkinkan Anda untuk mendorong sistem lebih jauh.

• Lakukan uji breakpoint hanya ketika sistem diketahui dapat berfungsi di bawah semua jenis uji lainnya.

Uji breakpoint mungkin menjadi lebih jauh jika sistem berfungsi buruk dengan jenis pengujian sebelumnya.

Breakpoint Testing di k6

Uji breakpoint sangat sederhana. Beban meningkat perlahan hingga tingkat yang sangat tinggi. Uji ini tidak memiliki dataran tinggi, penurunan beban, atau langkah lainnya. Dan biasanya gagal sebelum mencapai titik yang ditentukan.

k6 menawarkan dua cara untuk meningkatkan aktivitas: meningkatkan VU (Virtual Users) atau meningkatkan throughput (model terbuka dan tertutup). Berbeda dengan jenis uji beban lainnya, yang harus dihentikan ketika sistem mulai menurun, uji breakpoint terus meningkatkan beban meskipun sistem mulai menurun. Hal ini membuatnya disarankan untuk menggunakan ramping-arrival-rate untuk uji breakpoint.

Uji ini terus meningkatkan beban atau VU hingga mencapai titik breaking atau batas sistem yang telah ditentukan, pada titik tersebut uji dihentikan atau dibatalkan.

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

export const options = {
  // Konfigurasi utama untuk breakpoint pada bagian ini
  executor: 'ramping-arrival-rate', // Pastikan beban meningkat jika sistem melambat
  stages: [
    { duration: '2h', target: 20000 }, // Peningkatan perlahan hingga beban yang sangat besar
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // LANGKAH-LANGKAH LAIN
  // Anda bisa menambahkan lebih banyak langkah atau skrip yang lebih kompleks
  // Langkah1
  // Langkah2
  // dll.
};

Analisis Hasil

Uji breakpoint harus menyebabkan kegagalan sistem. Uji ini membantu mengidentifikasi titik kegagalan sistem dan bagaimana sistem berperilaku setelah mencapai batasnya.

Setelah batasan sistem diidentifikasi, tim memiliki dua pilihan: menerima batasan tersebut atau menyesuaikan sistem.

Jika keputusan diambil untuk menerima batasan, hasil uji akan membantu tim mempersiapkan dan bertindak ketika sistem mendekati batasan tersebut.

Tindakan yang bisa diambil meliputi:

• Mencegah pencapaian batas tersebut

• Meningkatkan sumber daya sistem

• Melakukan tindakan korektif terhadap perilaku sistem pada batasnya

• Menyesuaikan sistem untuk memperpanjang batasnya

Jika tindakan yang diambil adalah menyesuaikan sistem, lakukan penyesuaian, kemudian ulangi uji breakpoint untuk menemukan di mana dan apakah batasan sistem telah bergeser.

Tim harus menentukan jumlah pengulangan uji breakpoint, sejauh mana sistem dapat disesuaikan, dan sejauh mana batasan sistem dapat disesuaikan setelah setiap latihan.

API Load Testing

Uji beban API umumnya dimulai dengan beban kecil pada komponen-komponen yang terisolasi. Seiring dengan berkembangnya pengujian, strategi Anda dapat mempertimbangkan bagaimana cara menguji API secara lebih lengkap. Dalam proses ini, Anda akan menguji API Anda dengan lebih banyak permintaan, durasi yang lebih lama, dan cakupan uji yang lebih luas—dari komponen terisolasi hingga alur kerja end-to-end yang lengkap.

Saat merancang pengujian API Anda, pertama-tama pertimbangkan mengapa Anda ingin menguji API tersebut:

• Alur atau komponen apa yang ingin Anda uji?

• Bagaimana Anda akan menjalankan pengujian tersebut?

• Kriteria apa yang menentukan kinerja yang dapat diterima?

Setelah Anda dapat menjawab pertanyaan-pertanyaan ini, strategi pengujian API Anda kemungkinan akan mengikuti prosedur berikut:

1. Menulis Skrip Uji: Tulis alur pengguna, parameterisasi data uji, dan kelompokkan URL.

2. Memastikan Kinerja dan Kebenaran: Gunakan Cek untuk memastikan respons sistem dan gunakan Ambang Batas untuk memastikan sistem beroperasi sesuai dengan SLO (Service Level Objective) Anda.

3. Membuat Model dan Menghasilkan Beban: Pilih executor untuk memodelkan beban yang sesuai dengan tujuan pengujian Anda. Pastikan generator beban ditempatkan di lokasi yang tepat.

4. Iterasi Uji Suite Anda: Seiring waktu, Anda akan dapat menggunakan kembali logika skrip (misalnya, alur log-in pengguna atau konfigurasi throughput). Anda juga akan dapat menjalankan pengujian dengan cakupan yang lebih luas atau sebagai bagian dari suite pengujian otomatis Anda.

Bagian-bagian berikut memberikan penjelasan spesifik dan contoh-contoh langkah dalam proses ini.

Identifikasi Komponen yang Akan Diuji

Sebelum memulai pengujian, identifikasi komponen yang ingin Anda uji. Apakah Anda ingin menguji satu endpoint atau seluruh alur kerja?

Skrip berikut menggunakan modul HTTP k6 untuk menguji satu endpoint.

import http from 'k6/http';

export default function () {
  const payload = JSON.stringify({
    name: 'lorem',
    surname: 'ipsum',
  });
  const headers = { 'Content-Type': 'application/json' };
  http.post('https://quickpizza.grafana.com/api/post', payload, { headers });
}

Ini adalah pengujian minimal, dengan satu panggilan ke satu komponen. Secara umum, suite pengujian Anda akan berkembang dari skrip seperti ini menuju alur kerja yang lebih kompleks dan lengkap. Dalam proses ini, suite pengujian Anda akan berkembang melalui piramida pengujian sebagai berikut:

1. Mengujii API yang Terisolasi: Menguji satu endpoint API seperti ab untuk menguji kinerja dasar, titik batas, atau ketersediaan. Jika komponen tidak memenuhi persyaratan kinerja, itu adalah hambatan. Secara umum, beban diatur dalam permintaan per detik.

2. Mengujii API Terintegrasi: Menguji satu atau lebih API yang berinteraksi dengan API internal atau eksternal lainnya. Fokus Anda mungkin pada pengujian satu sistem atau berbagai sistem.

3. Mengujii Alur API End-to-End: Meniru interaksi realistis antara API untuk menguji sistem secara keseluruhan. Fokusnya sering kali pada skenario pengguna yang sering dan penting.

Suite uji beban Anda harus mencakup berbagai macam pengujian. Namun, saat memulai, mulailah dengan yang kecil dan sederhana, menguji API individual dan pengujian integrasi yang tidak rumit.

Menentukan Alasan Pengujian

Sebelum mengonfigurasi beban uji, Anda harus mengetahui pola lalu lintas seperti apa yang ingin Anda uji pada API tersebut. Uji beban biasanya bertujuan untuk melakukan salah satu dari dua hal:

• Memvalidasi keandalan di bawah lalu lintas yang diharapkan.

• Menemukan masalah dan batas sistem di bawah lalu lintas yang tidak biasa.

Misalnya, tim Anda mungkin membuat satu set uji untuk alur pengguna yang sering terjadi pada lalu lintas rata-rata, dan satu set lagi untuk menemukan titik kegagalan pada API. Meskipun logika pengujian tetap sama, bebannya bisa berubah.

Tujuan pengujian menentukan jenis pengujian, yang pada gilirannya menentukan beban pengujian. Pertimbangkan jenis-jenis pengujian berikut, yang sesuai dengan profil beban tujuan yang berbeda:

1. Pengujian Asap (Smoke Test): Memverifikasi bahwa sistem berfungsi dengan beban minimal.

2. Pengujian Beban “Rata-Rata” (Average Load Test): Menemukan bagaimana sistem berfungsi dengan lalu lintas yang tipikal.

3. Pengujian Stres (Stress Test): Menemukan bagaimana sistem berfungsi dengan beban lalu lintas puncak.

4. Pengujian Spike (Spike Test): Menemukan bagaimana sistem berfungsi dengan lonjakan lalu lintas yang mendadak dan besar.

5. Pengujian Breakpoint (Breakpoint Test): Secara progresif menaikkan lalu lintas untuk menemukan titik-titik kegagalan sistem.

6. Pengujian Soak (Soak Test): Menemukan apakah atau kapan sistem mengalami penurunan kinerja di bawah beban durasi panjang.

Jenis pengujian yang Anda pilih akan memberi petunjuk bagaimana Anda merencanakan dan menyusun pengujian Anda. Namun, setiap aplikasi, organisasi, dan proyek pengujian berbeda. Rekomendasi kami selalu:

“Mulailah dengan yang sederhana dan uji secara berkala. Iterasi dan kembangkan suite pengujian.”

Setelah Anda memutuskan profil beban, Anda dapat menjadwalkannya dengan opsi k6.

Memodelkan Beban Kerja

Untuk mengonfigurasi beban kerja, gunakan opsi uji. Beban uji mengonfigurasi lalu lintas yang dihasilkan oleh uji. k6 menyediakan dua cara utama untuk memodelkan beban:

• Melalui pengguna virtual (VUs), untuk mensimulasikan pengguna yang bersamaan

• Melalui permintaan per detik, untuk mensimulasikan throughput nyata dunia

Catatan

Secara umum, uji beban Anda harus menambahkan sleep time. Sleep membantu mengontrol generator beban dan mensimulasikan pola lalu lintas pengguna manusia dengan lebih baik.

Namun, ketika datang ke pengujian beban API, rekomendasi tentang slepp ini memiliki beberapa kualifikasi. Jika menguji komponen yang terisolasi, Anda mungkin hanya peduli tentang kinerja di bawah throughput yang telah ditentukan sebelumnya. Tetapi, bahkan dalam kasus ini, sleep dapat membantu Anda menghindari terlalu membebani generator beban, dan menyertakan beberapa milidetik acak sleep dapat menghindari masalah konkurensi yang tidak disengaja.

Saat menguji API terhadap alur kerja manusia normal, tambahkan sleep seperti pada pengujian normal.

Pengguna Virtual (Virtual Users)

Ketika Anda memodelkan beban berdasarkan VUs, opsi beban dasar adalah:

• vus

• duration

• iterations

Anda dapat mendefinisikan opsi ini dalam skrip pengujian. Dalam pengujian berikut, 50 pengguna bersamaan menjalankan alur default secara terus-menerus selama 30 detik.

import http from 'k6/http';

export const options = {
  vus: 50,
  duration: '30s',
};

export default function () {
  const payload = JSON.stringify({
    name: 'lorem',
    surname: 'ipsum',
  });
  const headers = { 'Content-Type': 'application/json' };
  http.post('https://quickpizza.grafana.com/api/post', payload, { headers });
}

Laju Permintaan (Request Rate)

Saat menganalisis kinerja endpoint API, beban biasanya dilaporkan berdasarkan laju permintaan—baik permintaan per detik atau per menit.

Untuk mengonfigurasi beban kerja berdasarkan target laju permintaan, gunakan eksekutor constant-arrival-rate.

constant-arrival-rate menetapkan laju iterasi konstan yang mengeksekusi fungsi skrip. Setiap iterasi dapat menghasilkan satu atau beberapa permintaan.

Untuk mencapai target laju permintaan (RequestsRate), ikuti pendekatan ini:

1. Setel frekuensi laju ke unit waktu dari target. Per detik atau per menit.

2. Dapatkan jumlah permintaan per iterasi (RequestsPerIteration).

3. Setel laju iterasi ke target permintaan per detik dibagi dengan jumlah permintaan per iterasi. rate = RequestsRate ÷ RequestsPerIteration.

Untuk mencapai target 50 permintaan/detik dengan contoh sebelumnya:

1. Setel opsi timeUnit ke 1s.

2. Jumlah permintaan per iterasi adalah 1.

3. Setel opsi rate ke 50/1 (sehingga menjadi 50).

import http from 'k6/http';

export const options = {
  scenarios: {
    my_scenario1: {
      executor: 'constant-arrival-rate',
      duration: '30s', // durasi total
      preAllocatedVUs: 50, // untuk mengalokasikan sumber daya runtime

      rate: 50, // jumlah iterasi konstan dengan `timeUnit`
      timeUnit: '1s',
    },
  },
};

export default function () {
  const payload = JSON.stringify({
    name: 'lorem',
    surname: 'ipsum',
  });
  const headers = { 'Content-Type': 'application/json' };
  http.post('https://quickpizza.grafana.com/api/post', payload, { headers });
}

Pengujian ini menghasilkan jumlah total permintaan HTTP dan RPS pada metrik http_reqs:

# nilai yang dilaporkan mendekati target 50 RPS
http_reqs......................: 1501   49.84156/s

# laju iterasi sama dengan rps, karena setiap iterasi hanya menjalankan satu permintaan
iterations.....................: 1501   49.84156/s

Dengan eksekutor constant-arrival-rate, beban tetap konstan selama pengujian. Untuk menaikkan atau menurunkan laju permintaan, gunakan eksekutor ramping-arrival-rate sebagai gantinya.

Untuk semua cara memodelkan beban di k6, lihat Scenarios.

Verifikasi Fungsionalitas dengan Cek

Secara tradisional, uji kinerja lebih mengutamakan:

• Latensi, seberapa cepat sistem merespons

• Ketersediaan, seberapa sering sistem mengembalikan kesalahan

Metrik http_req_duration melaporkan latensi, dan http_req_failed melaporkan tingkat kesalahan untuk permintaan HTTP. Hasil uji sebelumnya memberikan hasil berikut:

http_req_duration..............: avg=106.14ms min=102.54ms med=104.66ms max=198.93ms p(90)=113.78ms p(95)=114.58ms
    { expected_response:true }...: avg=106.14ms min=102.54ms med=104.66ms max=198.93ms p(90)=113.78ms p(95)=114.58ms
http_req_failed................: 0.00% ✓ 0    ✗ 1501

Analisis uji Anda mungkin perlu melampaui apa yang tersedia dengan metrik default. Untuk analisis hasil yang lebih bermakna, Anda mungkin juga ingin memverifikasi fungsionalitas dan melaporkan kesalahan.

Beberapa kegagalan aplikasi hanya terjadi dalam kondisi beban tertentu, seperti lalu lintas yang tinggi. Kesalahan ini sulit ditemukan. Untuk menemukan penyebab kegagalan dengan lebih cepat, instrumentasikan API Anda dan verifikasi bahwa permintaan mendapatkan respons yang diharapkan. Untuk memverifikasi logika aplikasi di k6, Anda dapat menggunakan Cek.

Cek memvalidasi kondisi selama eksekusi uji. Sebagai contoh, Anda dapat menggunakan cek untuk memverifikasi dan melacak respons API. Dengan cek, Anda dapat mengonfirmasi respons API yang diharapkan, seperti status HTTP atau data yang dikembalikan.

Skrip untuk memverifikasi status respons HTTP, header, dan payload.

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

export const options = {
  scenarios: {
    my_scenario1: {
      executor: 'constant-arrival-rate',
      duration: '30s', // durasi total
      preAllocatedVUs: 50, // untuk mengalokasikan sumber daya runtime

      rate: 50, // jumlah iterasi konstan dengan `timeUnit`
      timeUnit: '1s',
    },
  },
};

export default function () {
  const payload = JSON.stringify({
    name: 'lorem',
    surname: 'ipsum',
  });
  const headers = { 'Content-Type': 'application/json' };
  const res = http.post('https://quickpizza.grafana.com/api/post', payload, { headers });

  check(res, {
    'Post status is 200': (r) => res.status === 200,
    'Post Content-Type header': (r) => res.headers['Content-Type'] === 'application/json',
    'Post response name': (r) => res.status === 200 && res.json().name === 'lorem',
  });
}

Dalam cuplikan ini, semua cek berhasil:

my_scenario1 ✓ [======================================] 00/50 VUs  30s  50.00 iters/s
     ✓ Post status is 200
     ✓ Post Content-Type header
     ✓ Post response name

Setelah beban meningkat menjadi 300 permintaan per detik, hasilnya mengembalikan 8811 permintaan yang berhasil dan 7 kegagalan:

my_scenario1 ✓ [======================================] 000/300 VUs  30s  300.00 iters/s
     ✗ Post status is 200
      ↳  99% — ✓ 8811 / ✗ 7
     ✗ Post Content-Type header
      ↳  99% — ✓ 8811 / ✗ 7
     ✗ Post response name
      ↳  99% — ✓ 8811 / ✗ 7

Secara default, cek yang gagal tidak akan menyebabkan kegagalan atau penghentian uji. Dalam hal ini, cek berbeda dari cara kerja asersi pada jenis pengujian lainnya. Uji beban dapat menjalankan ribuan atau jutaan iterasi skrip, masing-masing dengan puluhan asersi.

Beberapa tingkat kegagalan dapat diterima, sesuai dengan “jumlah sembilan” dari SLO Anda atau anggaran kesalahan organisasi Anda.

Uji Tujuan Keandalan Anda dengan Ambang Batas

Setiap uji coba harus memiliki tujuan. Organisasi teknik menetapkan tujuan keandalan mereka menggunakan Service Level Objectives (SLOs) untuk memvalidasi ketersediaan, kinerja, atau persyaratan kinerja lainnya.

SLO dapat didefinisikan pada berbagai cakupan, seperti pada tingkat komponen infrastruktur, API, atau seluruh aplikasi. Beberapa contoh SLO mungkin seperti:

• 99% API yang mengembalikan informasi produk merespons dalam waktu kurang dari 600ms.

• 99,99% permintaan login yang gagal merespons dalam waktu kurang dari 1000ms.

Desain uji beban Anda dengan kriteria lulus/gagal untuk memvalidasi SLO, tujuan keandalan, atau metrik penting lainnya. Untuk memastikan sistem Anda mencapai SLO-nya, uji secara teratur, baik di lingkungan pra-produksi maupun produksi.

Di k6, Anda dapat menggunakan Ambang Batas untuk menetapkan kriteria lulus/gagal uji coba. Skrip ini mengkodifikasi dua SLO dalam objek ambang batas, satu tentang tingkat kesalahan (ketersediaan) dan satu lagi tentang durasi permintaan (latensi).

export const options = {
  thresholds: {
    http_req_failed: ['rate<0.01'], // kesalahan http harus kurang dari 1%
    http_req_duration: ['p(95)<200'], // 95% permintaan harus di bawah 200ms
  },
  scenarios: {
    my_scenario1: {
      executor: 'constant-arrival-rate',
      duration: '30s', // durasi total
      preAllocatedVUs: 50, // untuk mengalokasikan sumber daya runtime

      rate: 50, // jumlah iterasi konstan dalam waktu `timeUnit`
      timeUnit: '1s',
    },
  },
};

Ketika k6 menjalankan uji coba, output uji coba menunjukkan apakah metrik berada dalam ambang batas, ✅, atau apakah melebihi batas, ❌. Dalam output ini, uji coba memenuhi kedua ambang batas.

Contoh Output:

✓ http_req_duration..............: avg=104.7ms  min=101.87ms med=103.92ms max=120.68ms p(90)=107.2ms  p(95)=111.38ms
    { expected_response:true }...: avg=104.7ms  min=101.87ms med=103.92ms max=120.68ms p(90)=107.2ms  p(95)=111.38ms
✓ http_req_failed................: 0.00%   ✓ 0         ✗ 1501

Contoh Uji Gagal:

Jika uji gagal, CLI k6 akan mengembalikan kode keluar non-nol—syarat penting untuk otomatisasi uji coba. Berikut adalah contoh output untuk uji coba yang gagal dengan ambang batas bahwa 95 persen permintaan selesai dalam waktu kurang dari 50ms:

✗ http_req_duration..............: avg=105.14ms min=102.01ms med=103.86ms max=171.56ms p(90)=112.4ms  p(95)=113.18ms

Pertimbangan Scripting

Jika Anda pernah menulis uji coba sebelumnya, penulisan skrip k6 seharusnya terasa familiar. Uji coba k6 ditulis dalam JavaScript, dan desain API k6 memiliki kesamaan dengan kerangka uji coba lainnya.

Namun, berbeda dengan uji coba lainnya, uji beban menjalankan skripnya ratusan, ribuan, atau bahkan jutaan kali. Kehadiran beban menciptakan beberapa kekhawatiran spesifik. Ketika Anda menguji API dengan k6, pertimbangkan aspek-aspek desain skrip berikut.

Parameterisasi Data

Parameterisasi data terjadi ketika Anda mengganti data uji yang telah diprogram dengan nilai dinamis. Parameterisasi mempermudah pengelolaan uji beban dengan pengguna dan panggilan API yang bervariasi. Sebagai contoh, pertimbangkan file JSON dengan daftar informasi pengguna:

{
  "users": [
    { "username": "lorem", "surname": "ipsum" },
    { "username": "dolorem", "surname": "ipsum" }
  ]
}

Anda dapat melakukan parameterisasi data pengguna dengan objek SharedArray seperti berikut:

import { check } from 'k6';
import http from 'k6/http';
import { SharedArray } from 'k6/data';

const users = new SharedArray('users.json', function () {
  return JSON.parse(open('./users.json')).users;
});

export const options = {};

export default function () {
  const user = users[Math.floor(Math.random() * users.length)];
  const payload = JSON.stringify({
    name: user.username,
    surname: user.surname,
  });

  const headers = { 'Content-Type': 'application/json' };
  const res = http.post('https://quickpizza.grafana.com/api/post', payload, {
    headers,
  });

  check(res, {
    'Post status is 200': (r) => res.status === 200,
    'Post Content-Type header': (r) => res.headers['Content-Type'] === 'application/json',
    'Post response name': (r) => res.status === 200 && res.json().name === user.username,
  });
}

Penanganan Error dan Penerimaan Kegagalan

Ingat untuk mengimplementasikan penanganan error dalam logika uji coba. Di bawah beban yang cukup berat, SUT (sistem yang diuji) dapat gagal dan mulai merespons dengan kesalahan. Meskipun uji coba mungkin dirancang untuk menyebabkan kegagalan, terkadang kita fokus hanya pada skenario terbaik dan melupakan pentingnya mempertimbangkan error.

Skrip uji coba harus menangani kesalahan API untuk menghindari pengecualian saat runtime dan memastikan bahwa uji coba menguji bagaimana SUT berperilaku di bawah saturasi sesuai tujuan uji.

Penggunaan Kembali Skrip Uji dan Modularisasi

Uji beban dapat memiliki ruang lingkup yang sangat besar, dan seringkali melibatkan berbagai jenis uji coba. Tim biasanya memulai dengan uji coba beban yang sederhana atau kritis dan terus menambahkan uji untuk alur pengguna baru, pola lalu lintas, fitur, sistem, dll.

Untuk meminimalkan pekerjaan berulang, coba untuk menggunakan kembali skrip uji dan modularisasi fungsi serta logika uji.

Lokasi Generator Beban

Saat merencanakan uji coba, pertimbangkan lokasi generator beban Anda, yaitu mesin yang menjalankan uji coba. Terkadang, menjalankan uji coba dari lokasi tertentu merupakan persyaratan uji.

API Internal

Tes end-to-end API mencoba meniru alur pengguna dunia nyata, yang mengakses API publik dari sistem eksternal. API lainnya bersifat internal dan tidak dapat dijangkau dari luar. Anda dapat menggunakan k6 untuk mengujinya dalam beberapa cara berbeda.

Alat Pendukung

Anda mungkin ingin menggunakan k6 bersama dengan alat API lainnya untuk memperluas kemampuan pengujian Anda.

Recap & Praktek

Pengujian Performa API di Dunia Nyata dengan k6

K6 adalah alat pengujian performa open-source yang dirancang khusus untuk pengujian API dan aplikasi web. Berikut adalah panduan langkah demi langkah untuk melakukan pengujian performa API menggunakan k6:

Langkah 1: Instalasi k6

Pertama, Anda perlu menginstal k6 di sistem Anda:

Untuk Windows (menggunakan Chocolatey):

choco install k6

Untuk macOS (menggunakan Homebrew):

brew install k6

Untuk Linux (menggunakan apt):

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb 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

Menggunakan Docker:

docker pull grafana/k6

Cara Kerja k6 dan Mekanisme Pengelolaan Virtual Users

K6 adalah alat pengujian performa berbasis JavaScript yang didesain untuk mensimulasikan beban pada API, website, dan layanan backend. Berikut penjelasan tentang cara kerjanya, pengelolaan virtual users, dan eksekusi fungsinya:

1. Arsitektur dan Cara Kerja k6

K6 beroperasi dengan model eksekusi sebagai berikut:

1. JavaScript Runtime: K6 menggunakan mesin JavaScript Goja (Go-based JS interpreter) bukan Node.js atau browser. Ini memungkinkan pengelolaan memori yang lebih efisien dan performa yang lebih tinggi.

2. Event Loop: K6 mengadopsi model event loop mirip dengan Node.js tetapi dioptimalkan untuk pengujian beban.

3. Single Process, Multi-threaded: Secara default, k6 berjalan sebagai proses tunggal dengan multi-thread, yang memungkinkan penskalaan yang efisien pada mesin uji.

4. Execution Model: Setiap skenario pengujian dalam k6 didefinisikan dalam sebuah fungsi JavaScript, biasanya fungsi default(), yang mewakili satu iterasi dari aktivitas pengguna.

2. Pengelolaan Virtual Users (VUs)

Virtual User (VU) adalah abstraksi dari pengguna nyata dalam k6:

1. Isolasi: Setiap VU dijalankan dalam thread terpisah dan memiliki konteks JavaScript terpisah.

2. Independensi: VU berjalan independen satu sama lain, mirip dengan bagaimana pengguna nyata berperilaku.

3. Iterasi Berulang: Setiap VU akan mengeksekusi fungsi default() berulang kali selama durasi pengujian.

4. Lifecycle VU:

   • Initialization: Membuat thread dan lingkungan JavaScript baru

   • Setup: Menjalankan fungsi setup() (jika ada) - ini dijalankan sekali sebelum semua VU mulai

   • Execution: Menjalankan fungsi default() berulang kali

   • Teardown: Menjalankan fungsi teardown() (jika ada) - ini dijalankan sekali setelah semua VU selesai

   • Cleanup: Membersihkan sumber daya

3. Flow Pengelolaan VU Berdasarkan Skenario

K6 mendukung beberapa tipe executor (pengelola VU):

a. Shared Iterations

• Cara Kerja: Semua VU bersaing untuk menyelesaikan sejumlah iterasi yang ditentukan

• Flow:

  • Inisialisasi semua VU

  • Setiap VU mengeksekusi iterasi dari pool yang sama

  • VU yang lebih cepat akan mengeksekusi lebih banyak iterasi

export const options = {
  scenarios: {
    shared_iter_scenario: {
      executor: 'shared-iterations',
      vus: 10,
      iterations: 100,
      maxDuration: '30s',
    },
  },
};

b. Per VU Iterations

• Cara Kerja: Setiap VU menjalankan jumlah iterasi yang sama

• Flow:

  • Inisialisasi semua VU

  • Setiap VU mengeksekusi jumlah iterasi yang ditentukan secara independen

export const options = {
  scenarios: {
    per_vu_scenario: {
      executor: 'per-vu-iterations',
      vus: 10,
      iterations: 10,
      maxDuration: '30s',
    },
  },
};

c. Constant VUs

• Cara Kerja: Jumlah VU tetap konstan selama durasi yang ditentukan

• Flow:

  • Inisialisasi semua VU

  • Semua VU mengeksekusi fungsi default() berulang kali selama durasi yang ditentukan

export const options = {
  scenarios: {
    constant_scenario: {
      executor: 'constant-vus',
      vus: 10,
      duration: '3m',
    },
  },
};

d. Ramping VUs (Stages)

• Cara Kerja: Jumlah VU meningkat atau menurun selama durasi tertentu

• Flow:

  • VU diinisialisasi atau dihentikan sesuai dengan tahapan yang dikonfigurasi

  • VU aktif mengeksekusi fungsi default() berulang kali

export const options = {
  stages: [
    { duration: '30s', target: 20 }, // Ramp-up ke 20 VU
    { duration: '1m', target: 20 },  // Tetap di 20 VU
    { duration: '30s', target: 0 },  // Ramp-down ke 0 VU
  ],
};

e. Arrival Rate

• Cara Kerja: Menjaga tingkat kedatangan permintaan konstan (RPS - Requests Per Second)

• Flow:

  • k6 secara dinamis mengelola VU untuk mencapai rate yang ditentukan

  • VU dibuat atau didaur ulang sesuai kebutuhan untuk mempertahankan rate

export const options = {
  scenarios: {
    constant_rate: {
      executor: 'constant-arrival-rate',
      rate: 30,                 // 30 iterasi per timeUnit
      timeUnit: '1s',           // 1 detik
      duration: '1m',           // Selama 1 menit
      preAllocatedVUs: 10,      // VU awal
      maxVUs: 50,               // Batas maksimum VU
    },
  },
};

4. Berapa Kali Fungsi Dieksekusi

Jumlah eksekusi fungsi default() tergantung pada konfigurasi skenario:

1. Untuk Shared Iterations:

   • Total eksekusi = jumlah iterasi yang dikonfigurasi

   • Contoh: 100 iterasi dengan 10 VU = 100 total eksekusi

2. Untuk Per VU Iterations:

   • Total eksekusi = jumlah VU × jumlah iterasi per VU

   • Contoh: 10 VU dengan 10 iterasi masing-masing = 100 total eksekusi

3. Untuk Constant VUs atau Ramping VUs:

   • Total eksekusi = ∑(jumlah VU pada waktu t × tingkat iterasi)

   • Iterasi terus berlanjut selama durasi pengujian

   • Contoh: 10 VU selama 60 detik dengan iterasi 1/detik = ~600 eksekusi

4. Untuk Arrival Rate:

   • Total eksekusi = tingkat kedatangan × durasi

   • Contoh: 30 iterasi/detik selama 60 detik = 1800 total eksekusi

5. Mekanisme Iterasi Internal

Saat k6 menjalankan fungsi default():

1. Iterasi Sekuensial: Setiap VU mengeksekusi fungsi default() secara sekuensial, tidak secara paralel.

2. Kontrol Iterasi:

   • VU akan menjalankan iterasi berikutnya segera setelah iterasi saat ini selesai

   • Jika sleep() digunakan, VU akan menunggu waktu yang ditentukan sebelum iterasi berikutnya

   • Tanpa sleep(), iterasi akan berjalan secepat mungkin dalam batas CPU dan jaringan

3. Throttling:

   • Fungsi sleep() digunakan untuk mensimulasikan jeda antar aksi pengguna

   • Tanpa throttling, tes akan menjalankan iterasi maksimum yang memungkinkan, yang mungkin tidak realistis

6. Contoh Perhitungan Eksekusi

Skenario: Constant VUs dengan 10 VU selama 60 detik

• Jika setiap iterasi menggunakan sleep(1) (1 detik jeda):

  • Satu VU dapat mengeksekusi ~60 iterasi selama 60 detik

  • 10 VU akan mengeksekusi ~600 iterasi total

• Jika setiap iterasi membutuhkan 200ms untuk menyelesaikan request + sleep(1):

  • Satu VU dapat mengeksekusi ~50 iterasi (1.2 detik per iterasi)

  • 10 VU akan mengeksekusi ~500 iterasi total

Pemahaman tentang cara k6 mengelola VU dan eksekusi fungsi sangat penting untuk menyusun skenario pengujian yang akurat dan mencerminkan penggunaan dunia nyata. Dengan mengoptimalkan konfigurasi VU, Anda dapat mensimulasikan berbagai pola lalu lintas dan mengidentifikasi batasan performa aplikasi Anda.

Langkah 2: Membuat Skrip Pengujian Dasar

K6 menggunakan JavaScript untuk skrip pengujian. Buat file baru bernama api-test.js:

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

export default function() {
  // Kirim request GET ke endpoint API
  let response = http.get('https://api.example.com/endpoint');
  
  // Validasi response
  check(response, {
    'status adalah 200': (r) => r.status === 200,
    'response time kurang dari 500ms': (r) => r.timings.duration < 500
  });
  
  // Tunggu sebentar sebelum request berikutnya
  sleep(1);
}

Langkah 3: Konfigurasi Skenario Pengujian

Sesuaikan skrip untuk mengatur skenario pengujian yang sesuai dengan kebutuhan Anda:

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

// Konfigurasi pengujian
export const options = {
  stages: [
    { duration: '30s', target: 20 }, // Ramp-up ke 20 virtual users dalam 30 detik
    { duration: '1m', target: 20 },  // Bertahan di 20 VU selama 1 menit
    { duration: '30s', target: 0 },  // Ramp-down ke 0 VU
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% dari request harus selesai dalam 500ms
    http_req_failed: ['rate<0.01'],   // Toleransi kegagalan kurang dari 1%
  },
};

export default function() {
  let response = http.get('https://api.example.com/endpoint');
  
  check(response, {
    'status adalah 200': (r) => r.status === 200,
  });
  
  sleep(1);
}

Langkah 4: Menjalankan Pengujian

Jalankan pengujian Anda dengan perintah berikut:

k6 run api-test.js

Untuk menjalankan melalui Docker:

docker run -i grafana/k6 run - <api-test.js

Langkah 5: Analisis Hasil

Setelah pengujian selesai, k6 akan menampilkan rangkuman hasil pengujian yang mencakup:

• Request rate

• Response time (min, max, median, p90, p95)

• Tingkat keberhasilan/kegagalan

• Metrik throughput

• Validasi check

Langkah 6: Skenario Pengujian Lanjutan

1. Load Test (Pengujian Beban)

Pengujian untuk melihat performa sistem pada beban normal dan puncak:

export const options = {
  scenarios: {
    constant_request_rate: {
      executor: 'constant-arrival-rate',
      rate: 30, // 30 request per detik
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 20,
      maxVUs: 100,
    },
  },
};

2. Stress Test

Pengujian untuk mengetahui batas sistem dengan peningkatan beban secara bertahap:

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // Naik ke 100 VU
    { duration: '5m', target: 100 }, // Tetap di 100 VU
    { duration: '2m', target: 200 }, // Naik ke 200 VU
    { duration: '5m', target: 200 }, // Tetap di 200 VU
    { duration: '2m', target: 300 }, // Naik ke 300 VU
    { duration: '5m', target: 300 }, // Tetap di 300 VU
    { duration: '2m', target: 0 },   // Ramp-down ke 0 VU
  ],
};

3. Spike Test

Pengujian untuk mengevaluasi respons sistem terhadap lonjakan tiba-tiba:

export const options = {
  stages: [
    { duration: '10s', target: 10 },
    { duration: '1m', target: 10 },
    { duration: '10s', target: 300 }, // Spike!
    { duration: '3m', target: 300 },
    { duration: '10s', target: 10 },
    { duration: '1m', target: 10 },
  ],
};

4. Soak Test

Pengujian untuk memeriksa ketahanan sistem dalam durasi panjang:

export const options = {
  stages: [
    { duration: '2m', target: 50 },  // Ramp-up
    { duration: '3h', target: 50 },  // Tetap di beban konstan selama 3 jam
    { duration: '2m', target: 0 },   // Ramp-down
  ],
};

Langkah 7: Pengujian Skenario Dunia Nyata

Berikut contoh skrip pengujian yang lebih realistis untuk API:

import http from 'k6/http';
import { sleep, check, group } from 'k6';
import { Counter, Rate, Trend } from 'k6/metrics';
import { randomString } from 'https://jslib.k6.io/k6-utils/1.2.0/index.js';

// Metrik kustom
const successRate = new Rate('success_rate');
const errorRate = new Rate('error_rate');
const reqDuration = new Trend('req_duration');

// Konfigurasi pengujian
export const options = {
  stages: [
    { duration: '1m', target: 50 },   // Ramp-up ke 50 VU
    { duration: '3m', target: 50 },   // Tetap di 50 VU
    { duration: '1m', target: 100 },  // Naik ke 100 VU
    { duration: '5m', target: 100 },  // Tetap di 100 VU
    { duration: '1m', target: 0 },    // Ramp-down ke 0 VU
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% request selesai dalam 500ms
    http_req_failed: ['rate<0.01'],    // Kegagalan kurang dari 1%
    'success_rate': ['rate>0.95'],     // Tingkat keberhasilan lebih dari 95%
  },
};

// Data untuk pengujian
const BASE_URL = 'https://api.example.com';
const USERNAME = 'testuser';
const PASSWORD = 'testpassword';

// Fungsi untuk mendapatkan token otentikasi
function getAuthToken() {
  const loginRes = http.post(`${BASE_URL}/auth/login`, JSON.stringify({
    username: USERNAME,
    password: PASSWORD,
  }), {
    headers: { 'Content-Type': 'application/json' },
  });
  
  check(loginRes, {
    'login berhasil': (r) => r.status === 200,
    'token diperoleh': (r) => r.json('token') !== '',
  });
  
  return loginRes.json('token');
}

export function setup() {
  return { token: getAuthToken() };
}

export default function(data) {
  const token = data.token;
  const headers = {
    'Authorization': `Bearer ${token}`,
    'Content-Type': 'application/json',
  };
  
  // Simulasi alur kerja API
  group('Mendapatkan daftar item', function() {
    const listRes = http.get(`${BASE_URL}/api/items`, { headers });
    
    check(listRes, {
      'dapat mengambil daftar': (r) => r.status === 200,
      'daftar berisi item': (r) => r.json().length > 0,
    });
    
    // Catat waktu respons
    reqDuration.add(listRes.timings.duration);
    
    // Catat tingkat keberhasilan/kegagalan
    successRate.add(listRes.status === 200);
    errorRate.add(listRes.status !== 200);
    
    sleep(2);
  });
  
  // Buat item baru
  group('Buat item baru', function() {
    const payload = JSON.stringify({
      name: `Test Item ${randomString(8)}`,
      description: 'Item dibuat selama pengujian performa',
      price: Math.floor(Math.random() * 100) + 1,
    });
    
    const createRes = http.post(`${BASE_URL}/api/items`, payload, { headers });
    
    const success = check(createRes, {
      'item berhasil dibuat': (r) => r.status === 201,
      'ID item dikembalikan': (r) => r.json('id') !== undefined,
    });
    
    // Catat waktu respons dan tingkat keberhasilan
    reqDuration.add(createRes.timings.duration);
    successRate.add(success);
    errorRate.add(!success);
    
    // Jika berhasil dibuat, gunakan ID untuk operasi selanjutnya
    if (success && createRes.json('id')) {
      const itemId = createRes.json('id');
      
      // Mendapatkan detail item
      group('Mendapatkan detail item', function() {
        const getRes = http.get(`${BASE_URL}/api/items/${itemId}`, { headers });
        
        check(getRes, {
          'dapat mengambil detail item': (r) => r.status === 200,
          'data item sesuai': (r) => r.json('name').includes('Test Item'),
        });
        
        reqDuration.add(getRes.timings.duration);
        successRate.add(getRes.status === 200);
        errorRate.add(getRes.status !== 200);
      });
      
      // Perbarui item
      group('Perbarui item', function() {
        const updatePayload = JSON.stringify({
          description: 'Deskripsi diperbarui selama pengujian',
          price: Math.floor(Math.random() * 200) + 100,
        });
        
        const updateRes = http.put(`${BASE_URL}/api/items/${itemId}`, updatePayload, { headers });
        
        check(updateRes, {
          'item berhasil diperbarui': (r) => r.status === 200,
        });
        
        reqDuration.add(updateRes.timings.duration);
        successRate.add(updateRes.status === 200);
        errorRate.add(updateRes.status !== 200);
      });
      
      // Hapus item
      group('Hapus item', function() {
        const deleteRes = http.del(`${BASE_URL}/api/items/${itemId}`, null, { headers });
        
        check(deleteRes, {
          'item berhasil dihapus': (r) => r.status === 204,
        });
        
        reqDuration.add(deleteRes.timings.duration);
        successRate.add(deleteRes.status === 204);
        errorRate.add(deleteRes.status !== 204);
      });
    }
    
    sleep(3);
  });
}

export function teardown(data) {
  // Cleanup - Logout jika diperlukan
  const logoutRes = http.post(`${BASE_URL}/auth/logout`, null, {
    headers: {
      'Authorization': `Bearer ${data.token}`,
    },
  });
  
  check(logoutRes, {
    'logout berhasil': (r) => r.status === 200,
  });
}

Langkah 8: Menambahkan Pemantauan dan Visualisasi

K6 dapat diintegrasikan dengan alat visualisasi seperti Grafana:

1. Jalankan k6 dengan output InfluxDB:

k6 run --out influxdb=http://localhost:8086/k6 api-test.js

1. Gunakan dashboard Grafana yang telah dikonfigurasi untuk memvisualisasikan hasil pengujian secara real-time.

Penjelasan Metrik Penting dalam k6

K6 menyediakan berbagai metrik yang dapat Anda gunakan untuk mengevaluasi performa API:

1. http_reqs: Jumlah total permintaan HTTP

2. http_req_duration: Waktu total untuk permintaan (termasuk koneksi, TLS, mengirim, menunggu, menerima)

3. http_req_failed: Tingkat permintaan yang gagal

4. iterations: Jumlah iterasi fungsi default yang diselesaikan

5. vus: Jumlah virtual users aktif

6. http_req_waiting: Waktu menunggu response (Time to First Byte)

Tips Pengujian API di Dunia Nyata

1. Simulasikan penggunaan nyata: Buat skenario yang mencerminkan pola penggunaan aktual.

2. Gunakan data yang realistis: Hindari penggunaan data statis yang sama berulang kali.

3. Pertimbangkan caching: Evaluasi performa dengan dan tanpa caching.

4. Uji API endpoint penting: Fokus pada endpoint yang kritis untuk fungsi aplikasi.

5. Pertimbangkan throttling: Beberapa API memiliki batas rate limiting.

6. Alokasikan sumber daya yang cukup: Pastikan mesin pengujian memiliki sumber daya yang cukup.

7. Mulai kecil: Mulai dengan beban rendah dan tingkatkan secara bertahap.

8. Lakukan pengujian berulang: Jalankan pengujian beberapa kali untuk hasil yang konsisten.

Performa API sangat penting dalam aplikasi modern, dan k6 menyediakan alat yang kuat untuk memastikan API Anda dapat menangani beban yang diharapkan dengan andal. Dengan mengikuti langkah-langkah di atas, Anda dapat mengidentifikasi potensi masalah performa sebelum memengaruhi pengguna akhir.

Contoh Aplikasi CRUD

Aplikasi CRUD notes dengan stack Go (Chi), PostgreSQL, pgx pool, Squirrel query builder, dan Docker, serta load testing yang sesuai.

main.go

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"os"
	"time"

	"github.com/Masterminds/squirrel"
	"github.com/go-chi/chi/v5"
	"github.com/go-chi/chi/v5/middleware"
	"github.com/go-chi/cors"
	"github.com/jackc/pgx/v4/pgxpool"
)

// Note represents a note entity
type Note struct {
	ID        int64     `json:"id"`
	Title     string    `json:"title"`
	Content   string    `json:"content"`
	CreatedAt time.Time `json:"created_at"`
	UpdatedAt time.Time `json:"updated_at"`
}

// App holds application components
type App struct {
	Router *chi.Mux
	DB     *pgxpool.Pool
	Sq     squirrel.StatementBuilderType
}

// Initialize sets up the database connection and router
func (app *App) Initialize() error {
	// Get database connection string from environment variable
	dbURL := os.Getenv("DATABASE_URL")
	if dbURL == "" {
		dbURL = "postgres://postgres:postgres@db:5432/notesdb?sslmode=disable"
	}

	// Setup database connection pool
	poolConfig, err := pgxpool.ParseConfig(dbURL)
	if err != nil {
		return fmt.Errorf("error parsing database config: %w", err)
	}

	poolConfig.MaxConns = 25
	poolConfig.MinConns = 5
	poolConfig.MaxConnLifetime = time.Hour
	poolConfig.MaxConnIdleTime = 30 * time.Minute
	poolConfig.HealthCheckPeriod = time.Minute

	// Initialize the connection pool
	app.DB, err = pgxpool.ConnectConfig(context.Background(), poolConfig)
	if err != nil {
		return fmt.Errorf("error connecting to database: %w", err)
	}

	// Initialize Squirrel with PostgreSQL placeholder format
	app.Sq = squirrel.StatementBuilder.PlaceholderFormat(squirrel.Dollar)

	// Set up router with middleware
	app.Router = chi.NewRouter()
	app.Router.Use(middleware.Logger)
	app.Router.Use(middleware.Recoverer)
	app.Router.Use(middleware.Timeout(30 * time.Second))

	// Setup CORS
	app.Router.Use(cors.Handler(cors.Options{
		AllowedOrigins:   []string{"*"},
		AllowedMethods:   []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
		AllowedHeaders:   []string{"Accept", "Authorization", "Content-Type", "X-CSRF-Token"},
		ExposedHeaders:   []string{"Link"},
		AllowCredentials: true,
		MaxAge:           300,
	}))

	// Set up routes
	app.setupRoutes()

	return nil
}

// setupRoutes configures the API endpoints
func (app *App) setupRoutes() {
	app.Router.Route("/api/notes", func(r chi.Router) {
		r.Get("/", app.getAllNotes)
		r.Post("/", app.createNote)
		r.Get("/{id}", app.getNote)
		r.Put("/{id}", app.updateNote)
		r.Delete("/{id}", app.deleteNote)
	})

	// Health check endpoint
	app.Router.Get("/health", func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusOK)
		w.Write([]byte("OK"))
	})
}

// Run starts the application server
func (app *App) Run(addr string) {
	log.Printf("Server starting on %s", addr)
	log.Fatal(http.ListenAndServe(addr, app.Router))
}

// getAllNotes returns all notes
func (app *App) getAllNotes(w http.ResponseWriter, r *http.Request) {
	// Parse query parameters for pagination
	limit := 100 // Default limit
	offset := 0  // Default offset

	if r.URL.Query().Get("limit") != "" {
		fmt.Sscanf(r.URL.Query().Get("limit"), "%d", &limit)
	}
	if r.URL.Query().Get("offset") != "" {
		fmt.Sscanf(r.URL.Query().Get("offset"), "%d", &offset)
	}

	// Build query with Squirrel
	query, args, err := app.Sq.
		Select("id", "title", "content", "created_at", "updated_at").
		From("notes").
		OrderBy("created_at DESC").
		Limit(uint64(limit)).
		Offset(uint64(offset)).
		ToSql()

	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error building query: "+err.Error())
		return
	}

	// Execute query
	rows, err := app.DB.Query(r.Context(), query, args...)
	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error querying database: "+err.Error())
		return
	}
	defer rows.Close()

	// Process results
	var notes []Note
	for rows.Next() {
		var note Note
		if err := rows.Scan(&note.ID, &note.Title, &note.Content, &note.CreatedAt, &note.UpdatedAt); err != nil {
			respondWithError(w, http.StatusInternalServerError, "Error scanning row: "+err.Error())
			return
		}
		notes = append(notes, note)
	}

	if err := rows.Err(); err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error iterating rows: "+err.Error())
		return
	}

	respondWithJSON(w, http.StatusOK, notes)
}

// getNote returns a single note by ID
func (app *App) getNote(w http.ResponseWriter, r *http.Request) {
	// Get ID from URL parameter
	idStr := chi.URLParam(r, "id")
	var id int64
	_, err := fmt.Sscanf(idStr, "%d", &id)
	if err != nil {
		respondWithError(w, http.StatusBadRequest, "Invalid note ID")
		return
	}

	// Build query with Squirrel
	query, args, err := app.Sq.
		Select("id", "title", "content", "created_at", "updated_at").
		From("notes").
		Where(squirrel.Eq{"id": id}).
		ToSql()

	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error building query: "+err.Error())
		return
	}

	// Execute query
	var note Note
	err = app.DB.QueryRow(r.Context(), query, args...).Scan(
		&note.ID, &note.Title, &note.Content, &note.CreatedAt, &note.UpdatedAt,
	)

	if err != nil {
		respondWithError(w, http.StatusNotFound, "Note not found")
		return
	}

	respondWithJSON(w, http.StatusOK, note)
}

// createNote adds a new note
func (app *App) createNote(w http.ResponseWriter, r *http.Request) {
	var note Note
	decoder := json.NewDecoder(r.Body)
	if err := decoder.Decode(&note); err != nil {
		respondWithError(w, http.StatusBadRequest, "Invalid request payload")
		return
	}
	defer r.Body.Close()

	// Validate input
	if note.Title == "" {
		respondWithError(w, http.StatusBadRequest, "Title is required")
		return
	}

	now := time.Now()
	note.CreatedAt = now
	note.UpdatedAt = now

	// Build query with Squirrel
	query, args, err := app.Sq.
		Insert("notes").
		Columns("title", "content", "created_at", "updated_at").
		Values(note.Title, note.Content, note.CreatedAt, note.UpdatedAt).
		Suffix("RETURNING id").
		ToSql()

	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error building query: "+err.Error())
		return
	}

	// Execute query
	err = app.DB.QueryRow(r.Context(), query, args...).Scan(&note.ID)
	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error creating note: "+err.Error())
		return
	}

	respondWithJSON(w, http.StatusCreated, note)
}

// updateNote modifies an existing note
func (app *App) updateNote(w http.ResponseWriter, r *http.Request) {
	// Get ID from URL parameter
	idStr := chi.URLParam(r, "id")
	var id int64
	_, err := fmt.Sscanf(idStr, "%d", &id)
	if err != nil {
		respondWithError(w, http.StatusBadRequest, "Invalid note ID")
		return
	}

	// Parse request body
	var note Note
	decoder := json.NewDecoder(r.Body)
	if err := decoder.Decode(&note); err != nil {
		respondWithError(w, http.StatusBadRequest, "Invalid request payload")
		return
	}
	defer r.Body.Close()

	// Validate input
	if note.Title == "" {
		respondWithError(w, http.StatusBadRequest, "Title is required")
		return
	}

	note.ID = id
	note.UpdatedAt = time.Now()

	// Build query with Squirrel
	query, args, err := app.Sq.
		Update("notes").
		Set("title", note.Title).
		Set("content", note.Content).
		Set("updated_at", note.UpdatedAt).
		Where(squirrel.Eq{"id": id}).
		Suffix("RETURNING created_at").
		ToSql()

	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error building query: "+err.Error())
		return
	}

	// Execute query
	err = app.DB.QueryRow(r.Context(), query, args...).Scan(&note.CreatedAt)
	if err != nil {
		respondWithError(w, http.StatusNotFound, "Note not found")
		return
	}

	respondWithJSON(w, http.StatusOK, note)
}

// deleteNote removes a note
func (app *App) deleteNote(w http.ResponseWriter, r *http.Request) {
	// Get ID from URL parameter
	idStr := chi.URLParam(r, "id")
	var id int64
	_, err := fmt.Sscanf(idStr, "%d", &id)
	if err != nil {
		respondWithError(w, http.StatusBadRequest, "Invalid note ID")
		return
	}

	// Build query with Squirrel
	query, args, err := app.Sq.
		Delete("notes").
		Where(squirrel.Eq{"id": id}).
		ToSql()

	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error building query: "+err.Error())
		return
	}

	// Execute query
	res, err := app.DB.Exec(r.Context(), query, args...)
	if err != nil {
		respondWithError(w, http.StatusInternalServerError, "Error deleting note: "+err.Error())
		return
	}

	if res.RowsAffected() == 0 {
		respondWithError(w, http.StatusNotFound, "Note not found")
		return
	}

	respondWithJSON(w, http.StatusOK, map[string]string{"result": "success"})
}

// respondWithError handles error responses
func respondWithError(w http.ResponseWriter, code int, message string) {
	respondWithJSON(w, code, map[string]string{"error": message})
}

// respondWithJSON handles JSON responses
func respondWithJSON(w http.ResponseWriter, code int, payload interface{}) {
	response, err := json.Marshal(payload)
	if err != nil {
		w.WriteHeader(http.StatusInternalServerError)
		w.Write([]byte("Error marshalling JSON response"))
		return
	}
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(code)
	w.Write(response)
}

func main() {
	app := App{}

	// Initialize application
	if err := app.Initialize(); err != nil {
		log.Fatalf("Failed to initialize app: %v", err)
	}

	// Run server
	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
	}
	app.Run(":" + port)
}

init.sql

CREATE TABLE IF NOT EXISTS notes (
    id SERIAL PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    content TEXT,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL
);

-- Create index for faster searching
CREATE INDEX IF NOT EXISTS idx_notes_title ON notes(title);
CREATE INDEX IF NOT EXISTS idx_notes_created_at ON notes(created_at);

-- Insert some initial data
INSERT INTO notes (title, content, created_at, updated_at) VALUES
('Welcome to Notes App', 'This is a simple notes application built with Go, PostgreSQL, and Docker.', NOW(), NOW()),
('Getting Started', 'Use the API endpoints to create, read, update, and delete notes.', NOW(), NOW()),
('API Usage', 'The application provides RESTful endpoints for notes management.', NOW(), NOW());

Dockerfile

# Build stage
FROM golang:1.24-alpine AS builder

# Set working directory
WORKDIR /app

# Install necessary build tools
RUN apk add --no-cache git

# Copy go mod and sum files
COPY go.mod go.sum ./

# Download dependencies
RUN go mod download

# Copy source code
COPY . .

# Build the application
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o notes-app .

# Final stage
FROM alpine:3.21

# Add CA certificates for HTTPS
RUN apk --no-cache add ca-certificates

WORKDIR /root/

# Copy the binary from the builder stage
COPY --from=builder /app/notes-app .

# Expose the application port
EXPOSE 8080

# Command to run the application
CMD ["./notes-app"]

compose.yaml

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    environment:
      - PORT=8080
      - DATABASE_URL=postgres://postgres:postgres@db:5432/notesdb?sslmode=disable
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped
    networks:
      - notes-network

  db:
    image: postgres:17-alpine
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=notesdb
    ports:
      - "5432:5432"
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - notes-network

networks:
  notes-network:
    driver: bridge

volumes:
  postgres-data:

load-test.js

import http from 'k6/http';
import { sleep, check, group } from 'k6';
import { Rate, Trend } from 'k6/metrics';
import { randomString } from 'https://jslib.k6.io/k6-utils/1.2.0/index.js';
import { htmlReport } from "https://raw.githubusercontent.com/benc-uk/k6-reporter/main/dist/bundle.js";

// Custom metrics
const successRate = new Rate('success_rate');
const errorRate = new Rate('error_rate');
const createNoteReqDuration = new Trend('create_note_duration');
const getNoteReqDuration = new Trend('get_note_duration');
const listNotesReqDuration = new Trend('list_notes_duration');
const updateNoteReqDuration = new Trend('update_note_duration');
const deleteNoteReqDuration = new Trend('delete_note_duration');

// Base configuration
const BASE_URL = __ENV.BASE_URL || 'http://localhost:8080';

// Configuration for test scenarios
export const options = {
  scenarios: {
    // Smoke test - lightweight test to verify the system works
    smoke_test: {
      executor: 'constant-vus',
      vus: 1,
      duration: '1m',
      tags: { test_type: 'smoke' },
      env: { SCENARIO: 'smoke' },
      exec: 'smokeTest',
    },

    // Load test - simulate expected load
    normal_load: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '1m', target: 10 },
        { duration: '3m', target: 10 },
        { duration: '1m', target: 0 },
      ],
      tags: { test_type: 'load' },
      env: { SCENARIO: 'load' },
      exec: 'loadTest',
    },

    // Stress test - find the breaking point
    stress_test: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '1m', target: 20 },
        { duration: '2m', target: 20 },
        { duration: '1m', target: 50 },
        { duration: '2m', target: 50 },
        { duration: '1m', target: 100 },
        { duration: '2m', target: 100 },
        { duration: '1m', target: 0 },
      ],
      tags: { test_type: 'stress' },
      env: { SCENARIO: 'stress' },
      exec: 'stressTest',
    },

    // Spike test - sudden traffic spikes
    spike_test: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '10s', target: 5 },
        { duration: '50s', target: 5 },
        { duration: '10s', target: 100 },
        { duration: '1m', target: 100 },
        { duration: '10s', target: 5 },
        { duration: '50s', target: 5 },
        { duration: '10s', target: 0 },
      ],
      tags: { test_type: 'spike' },
      env: { SCENARIO: 'spike' },
      exec: 'spikeTest',
    },

    // Soak test - evaluate system over long period
    soak_test: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '1m', target: 10 },
        { duration: '10m', target: 10 },
        { duration: '1m', target: 0 },
      ],
      tags: { test_type: 'soak' },
      env: { SCENARIO: 'soak' },
      exec: 'soakTest',
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
    'success_rate': ['rate>0.95'],
    'create_note_duration': ['p(95)<600'],
    'get_note_duration': ['p(95)<300'],
    'list_notes_duration': ['p(95)<800'],
    'update_note_duration': ['p(95)<600'],
    'delete_note_duration': ['p(95)<500'],
  },
};


// Create a note
function createNote() {
  const title = `Test Note ${randomString(8)}`;
  const content = `This is a test note created at ${new Date().toISOString()} with random content: ${randomString(50)}`;

  const payload = JSON.stringify({
    title: title,
    content: content
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
    },
  };

  const startTime = new Date().getTime();
  const res = http.post(`${BASE_URL}/api/notes`, payload, params);
  const duration = new Date().getTime() - startTime;

  createNoteReqDuration.add(duration);

  const success = check(res, {
    'note created successfully': (r) => r.status === 201,
    'response has id': (r) => r.json('id') !== undefined,
  });

  successRate.add(success);
  errorRate.add(!success);

  if (success) {
    return res.json('id');
  }

  return null;
}

// Get a note
function getNote(id) {
  const startTime = new Date().getTime();
  const res = http.get(`${BASE_URL}/api/notes/${id}`);
  const duration = new Date().getTime() - startTime;

  getNoteReqDuration.add(duration);

  const success = check(res, {
    'get note status is 200': (r) => r.status === 200,
    'get note returns correct id': (r) => r.json('id') === id,
  });

  successRate.add(success);
  errorRate.add(!success);

  return success;
}

// List notes
function listNotes(limit = 10, offset = 0) {
  const startTime = new Date().getTime();
  const res = http.get(`${BASE_URL}/api/notes?limit=${limit}&offset=${offset}`);
  const duration = new Date().getTime() - startTime;

  listNotesReqDuration.add(duration);

  const success = check(res, {
    'list notes status is 200': (r) => r.status === 200,
    'list notes returns array': (r) => Array.isArray(r.json()),
  });

  successRate.add(success);
  errorRate.add(!success);

  return success;
}

// Update a note
function updateNote(id) {
  const updatedTitle = `Updated Note ${randomString(8)}`;
  const updatedContent = `This note was updated at ${new Date().toISOString()} with new content: ${randomString(50)}`;

  const payload = JSON.stringify({
    title: updatedTitle,
    content: updatedContent
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
    },
  };

  const startTime = new Date().getTime();
  const res = http.put(`${BASE_URL}/api/notes/${id}`, payload, params);
  const duration = new Date().getTime() - startTime;

  updateNoteReqDuration.add(duration);

  const success = check(res, {
    'note updated successfully': (r) => r.status === 200,
    'updated title matches': (r) => r.json('title') === updatedTitle,
  });

  successRate.add(success);
  errorRate.add(!success);

  return success;
}

// Delete a note
function deleteNote(id) {
  const startTime = new Date().getTime();
  const res = http.del(`${BASE_URL}/api/notes/${id}`);
  const duration = new Date().getTime() - startTime;

  deleteNoteReqDuration.add(duration);

  const success = check(res, {
    'note deleted successfully': (r) => r.status === 200,
  });

  successRate.add(success);
  errorRate.add(!success);

  return success;
}

// Smoke test - very basic functionality check
export function smokeTest() {
  group('Smoke Test - Basic API Operations', function() {
    // List notes
    group('List Notes', function() {
      listNotes();
    });

    // Create a note
    let noteId = null;
    group('Create Note', function() {
      noteId = createNote();
    });

    if (noteId) {
      // Get the created note
      group('Get Note', function() {
        getNote(noteId);
      });

      // Update the note
      group('Update Note', function() {
        updateNote(noteId);
      });

      // Delete the note
      group('Delete Note', function() {
        deleteNote(noteId);
      });
    }

    sleep(1);
  });
}

// Load test - simulates typical user behavior under normal load
export function loadTest() {
  group('Load Test - Normal User Behavior', function() {
    // Simulate read-heavy usage (70% reads, 20% writes, 10% updates/deletes)
    // This is common for note-taking apps where users read more than they write

    const action = Math.random();
    let noteId = null;

    if (action < 0.7) {
      // 70% chance of reading operations
      const readAction = Math.random();

      if (readAction < 0.8) {
        // 80% of reads are list operations (56% of total)
        group('List Notes', function() {
          // Simulate different pagination requests
          const limit = [10, 20, 50][Math.floor(Math.random() * 3)];
          const offset = Math.floor(Math.random() * 5) * limit;
          listNotes(limit, offset);
        });
      } else {
        // 20% of reads are get operations (14% of total)
        group('Get Random Note', function() {
          // Get a random note ID between 1 and 10 (assuming some notes exist)
          const randomId = Math.floor(Math.random() * 10) + 1;
          getNote(randomId);
        });
      }
    } else if (action < 0.9) {
      // 20% chance of creating a new note
      group('Create New Note', function() {
        noteId = createNote();

        if (noteId && Math.random() < 0.3) {
          // 30% chance of immediate read after create
          sleep(0.5); // Slight pause to simulate user looking at new note
          getNote(noteId);
        }
      });
    } else {
      // 10% chance of update/delete operations
      const modifyAction = Math.random();

      // First create a note to modify
      group('Create Note for Modification', function() {
        noteId = createNote();
      });

      if (noteId) {
        if (modifyAction < 0.7) {
          // 70% of modifications are updates (7% of total)
          group('Update Note', function() {
            updateNote(noteId);
          });
        } else {
          // 30% of modifications are deletes (3% of total)
          group('Delete Note', function() {
            deleteNote(noteId);
          });
        }
      }
    }

    // Add think time to simulate realistic user behavior
    sleep(Math.random() * 3 + 1); // Random sleep between 1-4 seconds
  });
}

// Stress test - finds the breaking point
export function stressTest() {
  group('Stress Test - High Concurrency Operations', function() {
    // More aggressive test pattern with concurrent operations

    // Create multiple notes in quick succession
    const noteIds = [];
    for (let i = 0; i < 3; i++) {
      const id = createNote();
      if (id) noteIds.push(id);
      // Minimal sleep to allow some concurrent operations
      sleep(0.1);
    }

    // List notes with different parameters
    listNotes(20, 0);

    // Read, update and delete created notes
    for (const id of noteIds) {
      getNote(id);
      updateNote(id);
      deleteNote(id);
    }
  });
}

// Soak test - evaluate system over long period
export function soakTest() {
  group('Soak Test - Long Duration Load', function() {
    // Simulate normal load for an extended period
    for (let i = 0; i < 10; i++) {
      listNotes();
      sleep(10); // Add sleep to simulate prolonged usage
    }
  });
}

// Spike test - sudden traffic spikes
export function spikeTest() {
  group('Spike Test - Sudden Traffic Surge', function() {
    // Ramp up to 100 users, then spike to 200 users, and finally ramp down
    for (let i = 0; i < 5; i++) {
      listNotes();
      sleep(2); // Pause for a short time between requests
    }
  });
}

Jalankan perintah docker compose up -d --build dan Jalankan load test k6 run load-test.js