DEV Community

Cover image for Panduan Lengkap Pengujian Performa API
Walse
Walse

Posted on • Originally published at apidog.com

Panduan Lengkap Pengujian Performa API

Sebuah API bisa lolos semua pengujian fungsional tetapi tetap gagal di produksi. Responsnya benar, status code benar, skema benar, lalu mulai timeout saat seribu pengguna mengaksesnya bersamaan. Pengujian fungsional memastikan API bekerja sesuai kontrak. Pengujian kinerja memastikan API tetap cepat dan stabil saat menerima lalu lintas nyata.

Coba Apidog hari ini

Panduan ini membahas apa itu pengujian kinerja API, jenis pengujian yang perlu dijalankan, metrik yang harus dibaca, dan cara menjalankan pengujian kinerja langkah demi langkah di Apidog.

Apa itu pengujian kinerja API

Pengujian kinerja API mengukur perilaku API di bawah beban:

  • seberapa cepat API merespons
  • berapa banyak request yang dapat diproses
  • kapan latency mulai naik
  • kapan error mulai muncul
  • pada titik mana API gagal

Ini berbeda dari pengujian fungsional. Pengujian fungsional menjawab: “Apakah responsnya benar?” Pengujian kinerja menjawab: “Apakah responsnya tetap cepat dan andal saat sistem sibuk?”

Tujuannya adalah menemukan batas API sebelum pengguna menemukannya. Setiap API memiliki titik maksimum, yaitu saat waktu respons naik tajam, error bertambah, atau service berhenti merespons. Dengan pengujian kinerja, batas tersebut bisa ditemukan di lingkungan terkontrol sehingga Anda dapat memperbaikinya atau merencanakan kapasitas dengan lebih akurat.

API cocok untuk pengujian kinerja karena request dan responsnya mudah diukur. Tidak ada browser, rendering UI, atau interaksi visual. Anda mengirim request, mengukur respons, lalu membaca metriknya.

Jenis-jenis pengujian kinerja

“Pengujian kinerja” mencakup beberapa jenis pengujian. Gunakan jenis yang sesuai dengan pertanyaan yang ingin dijawab.

1. Load testing

Load testing menjalankan trafik normal atau trafik puncak yang Anda harapkan.

Gunakan ini untuk menjawab:

  • Apakah API mampu menangani beban harian?
  • Apakah API masih memenuhi target latency saat peak traffic?
  • Berapa throughput yang stabil?

Contoh target:

Endpoint: GET /products
Beban: 300 pengguna virtual
Durasi: 10 menit
Target: p95 < 200 ms, error rate < 1%
Enter fullscreen mode Exit fullscreen mode

2. Stress testing

Stress testing menaikkan beban melewati trafik yang diharapkan sampai API melambat atau gagal.

Gunakan ini untuk menjawab:

  • Di titik mana API mulai menurun?
  • Apakah API gagal secara bertahap atau langsung runtuh?
  • Apakah error muncul sebelum timeout?
  • Apakah data tetap aman saat sistem tertekan?

3. Spike testing

Spike testing memberi lonjakan trafik tajam dalam waktu singkat.

Gunakan ini jika sistem Anda mungkin menerima trafik mendadak, misalnya:

  • flash sale
  • kampanye marketing
  • notifikasi massal
  • konten viral
  • event tertentu

Sistem yang stabil pada beban konstan masih bisa gagal saat menerima lonjakan tiba-tiba.

4. Soak testing

Soak testing, atau endurance testing, menjalankan beban sedang dalam durasi panjang.

Gunakan ini untuk menemukan masalah yang baru muncul setelah beberapa jam atau hari, seperti:

  • memory leak
  • connection pool habis
  • file log memenuhi disk
  • koneksi database tidak dilepas
  • performa menurun perlahan

Masalah seperti ini biasanya tidak terlihat pada load test lima menit.

5. Smoke testing

Smoke testing adalah pengujian ringan sebelum menjalankan pengujian besar.

Gunakan ini untuk memastikan:

  • endpoint bisa diakses
  • data uji tersedia
  • autentikasi benar
  • skenario berjalan
  • konfigurasi test tidak salah

Jalankan smoke test sebelum load, stress, atau soak test agar tidak membuang waktu pada pengujian yang gagal karena setup.

Metrik yang penting

Pengujian kinerja menghasilkan banyak angka. Fokus pada metrik berikut.

Waktu respons

Waktu respons adalah durasi dari request dikirim sampai respons diterima.

Jangan hanya melihat rata-rata. Gunakan persentil:

  • p50: median
  • p95: 95% request lebih cepat dari angka ini
  • p99: 99% request lebih cepat dari angka ini

Rata-rata bisa terlihat aman, sementara sebagian kecil pengguna mengalami respons sangat lambat. Persentil membantu membaca tail latency, yaitu bagian lambat yang biasanya paling terasa oleh pengguna.

Throughput

Throughput adalah jumlah request yang selesai diproses per detik.

Biasanya ditulis sebagai:

requests/second
RPS
req/s
Enter fullscreen mode Exit fullscreen mode

Throughput menunjukkan kapasitas aktual API. Jika jumlah pengguna virtual naik tetapi throughput tidak naik, API kemungkinan sudah mencapai batasnya.

Pengguna bersamaan

Pengguna bersamaan atau virtual users adalah jumlah pemanggil simultan yang disimulasikan dalam pengujian.

Contoh:

100 virtual users
300 virtual users
500 virtual users
Enter fullscreen mode Exit fullscreen mode

Kapasitas API sering dinyatakan sebagai jumlah pengguna bersamaan maksimum yang masih bisa dilayani sebelum latency atau error melewati batas.

Error rate

Error rate adalah persentase request yang gagal.

Contoh:

Total request: 100.000
Request gagal: 1.200
Error rate: 1,2%
Enter fullscreen mode Exit fullscreen mode

API yang tetap cepat tetapi mulai mengembalikan banyak 500, 502, 503, atau timeout tetap gagal secara kinerja.

Pemanfaatan sumber daya

Pantau juga metrik server, terutama:

  • CPU
  • memori
  • koneksi database
  • disk I/O
  • network I/O
  • latency service downstream

Metrik ini membantu menemukan penyebab bottleneck.

Contoh interpretasi:

p95 naik + CPU 100%       => kemungkinan compute-bound
p95 naik + CPU rendah     => cek database, network, atau service eksternal
error naik + koneksi penuh => kemungkinan connection pool exhaustion
Enter fullscreen mode Exit fullscreen mode

Laporan kinerja yang baik menghubungkan metrik-metrik ini:

Pada 300 pengguna bersamaan:
- throughput: 850 req/s
- p95: 240 ms
- p99: 700 ms
- error rate: 0,4%

Pada 420 pengguna bersamaan:
- throughput: stagnan
- p95: 900 ms
- error rate: 1,2%
Enter fullscreen mode Exit fullscreen mode

Cara menjalankan pengujian kinerja API di Apidog

Apidog menyediakan pengujian beban di workspace yang sama dengan desain dan pengujian fungsional API. Dengan begitu, Anda bisa mulai dari endpoint atau skenario yang sudah ada.

Langkah 1: Pilih endpoint atau skenario

Mulai dari endpoint yang kritis untuk bisnis atau sering dipanggil.

Contoh endpoint:

GET /products
GET /users/{id}
POST /orders
POST /checkout
Enter fullscreen mode Exit fullscreen mode

Jika alur pengguna terdiri dari beberapa langkah, gunakan skenario pengujian multi-step.

Contoh skenario:

1. Login
2. Ambil profil pengguna
3. Ambil daftar produk
4. Buat order
5. Ambil status order
Enter fullscreen mode Exit fullscreen mode

Skenario seperti ini lebih realistis dibanding hanya membebani satu endpoint secara terpisah.

Langkah 2: Pastikan pengujian fungsional lulus

Sebelum mengukur performa, pastikan request sudah benar.

Cek:

  • status code sesuai
  • response body sesuai
  • schema valid
  • data penting tersedia
  • autentikasi berhasil
  • asertasi lulus

Jangan melakukan load test pada endpoint yang masih mengembalikan data salah. Perbaiki kebenaran lebih dulu, baru ukur kecepatannya.

Langkah 3: Tentukan konfigurasi beban

Tentukan jumlah pengguna virtual dan durasi pengujian.

Contoh konfigurasi awal:

Virtual users: 100
Ramp-up: 5 menit
Durasi: 10 menit
Target:
- p95 < 200 ms
- error rate < 1%
Enter fullscreen mode Exit fullscreen mode

Gunakan ramp-up bertahap agar trafik lebih realistis. Alih-alih langsung mengirim 500 pengguna, naikkan beban secara bertahap sehingga Anda bisa melihat di titik mana performa mulai berubah.

Contoh pola:

0 - 5 menit    : naik dari 0 ke 100 users
5 - 10 menit   : naik dari 100 ke 300 users
10 - 15 menit  : tahan di 300 users
Enter fullscreen mode Exit fullscreen mode

Langkah 4: Jalankan pengujian

Saat pengujian berjalan, pantau metrik utama:

  • waktu respons
  • p95 dan p99
  • throughput
  • error rate
  • perubahan metrik saat concurrency naik

Cari titik infleksi, yaitu saat latency mulai naik lebih cepat daripada kenaikan beban.

Contoh sinyal bottleneck:

Users naik dari 250 ke 300
Throughput hampir tidak naik
p95 naik dari 220 ms ke 600 ms
error mulai muncul
Enter fullscreen mode Exit fullscreen mode

Itu tanda API mendekati atau sudah melewati batas nyamannya.

Langkah 5: Baca hasil dan cari bottleneck

Setelah test selesai, tentukan batas praktis API.

Contoh:

p95 melewati 200 ms pada 280 users
error rate melewati 1% pada 420 users
throughput mulai stagnan pada 300 users
Enter fullscreen mode Exit fullscreen mode

Interpretasi:

API nyaman sampai sekitar 250 pengguna bersamaan.
Batas atas praktis sekitar 280 pengguna.
API mulai gagal sekitar 420 pengguna.
Enter fullscreen mode Exit fullscreen mode

Lalu cocokkan dengan metrik server:

  • CPU tinggi?
  • memori naik terus?
  • koneksi database penuh?
  • query lambat?
  • service eksternal melambat?
  • timeout bertambah?

Perbaiki bottleneck, lalu jalankan ulang pengujian untuk memastikan batasnya bergeser.

Langkah 6: Ekspor ke JMeter jika perlu skala lebih besar

Jika Anda perlu menjalankan beban terdistribusi di luar satu mesin, Apidog dapat mengekspor skenario ke JMeter. Dengan cara ini, definisi pengujian tetap sama, tetapi sumber beban bisa diskalakan.

Unduh Apidog untuk menjalankan pengujian beban pertama terhadap endpoint yang sudah Anda miliki.

Membaca hasil kinerja nyata

Angka tanpa interpretasi tidak cukup. Misalnya Anda menguji:

GET /products
Enter fullscreen mode Exit fullscreen mode

Konfigurasi:

Virtual users: naik dari 0 ke 500
Durasi: 5 menit
Target: p95 < 200 ms
Enter fullscreen mode Exit fullscreen mode

Hasilnya:

0 - 200 users:
- p95 stabil sekitar 180 ms
- throughput naik mengikuti beban
- error rate mendekati 0%

Sekitar 280 users:
- p95 mulai naik ke 240 ms, lalu 400 ms
- throughput mulai mendatar

Di atas 420 users:
- p95 mendekati 900 ms
- error rate melewati 1%
- beberapa request timeout
Enter fullscreen mode Exit fullscreen mode

Kesimpulannya:

API nyaman sampai sekitar 250 pengguna bersamaan.
Batas praktisnya sekitar 280 pengguna.
API mulai gagal sekitar 420 pengguna.
Enter fullscreen mode Exit fullscreen mode

Jika trafik puncak yang diharapkan adalah 200 pengguna bersamaan, kapasitas masih aman. Jika target trafik adalah 350 pengguna bersamaan, perlu optimasi sebelum rilis.

Pengujian kinerja tidak hanya menghasilkan status “lulus” atau “gagal”. Ia memberi peta kapasitas:

  • zona aman
  • zona mulai tertekan
  • zona gagal

Hambatan kinerja API yang umum

Saat pengujian menemukan batas atas, penyebabnya biasanya berasal dari pola yang berulang.

Kueri database lambat

Ini adalah penyebab paling umum.

Contoh masalah:

  • kolom belum diindeks
  • query terlalu luas
  • tidak ada pagination
  • pola N+1 query
  • join terlalu berat
  • filter tidak efisien

Sinyal umum:

Latency naik
CPU aplikasi rendah
Database CPU atau query time tinggi
Enter fullscreen mode Exit fullscreen mode

Jika ini terjadi, mulai dari query log dan execution plan.

Panggilan eksternal yang memblokir

API yang memanggil service eksternal secara sinkron akan mewarisi latency service tersebut.

Contoh dependency:

  • payment provider
  • email provider
  • layanan autentikasi
  • API pihak ketiga
  • microservice internal

Sinyal umum:

p95 naik hanya pada endpoint tertentu
timeout meningkat
CPU aplikasi tidak penuh
Enter fullscreen mode Exit fullscreen mode

Cek timeout, retry policy, dan apakah panggilan bisa dibuat asynchronous.

Connection pool exhaustion

Connection pool exhaustion terjadi saat aplikasi kehabisan koneksi ke database atau HTTP client.

Sinyal umum:

Request mengantre
Latency naik setelah durasi tertentu
Error muncul di bawah beban berkelanjutan
Enter fullscreen mode Exit fullscreen mode

Masalah ini sering muncul pada soak testing.

Serialisasi payload besar

Respons yang terlalu besar memperlambat API karena data harus:

  • diambil dari database
  • diproses aplikasi
  • diserialisasi
  • dikirim lewat jaringan
  • diparse oleh client

Contoh perbaikan:

  • pagination
  • field selection
  • kompresi
  • batasi nested object
  • hindari mengirim data yang tidak dipakai client

Pengujian kinerja menunjukkan di mana batasnya. Metrik sisi server membantu menjelaskan mengapa batas itu muncul.

Membangun pengujian kinerja ke dalam proses development

Pengujian kinerja sekali sebelum rilis besar memang berguna. Namun, pengujian rutin jauh lebih bernilai karena regresi performa sering muncul diam-diam.

Contoh perubahan kecil yang bisa menurunkan performa:

  • menambah query baru
  • menambah panggilan service downstream
  • menghapus index tanpa sadar
  • memperbesar payload respons
  • menambah validasi berat
  • mengubah pola caching

Tetapkan anggaran performa untuk endpoint penting.

Contoh:

GET /products
- p95 < 200 ms
- p99 < 800 ms
- error rate < 1%

POST /checkout
- p95 < 500 ms
- error rate < 0,5%
Enter fullscreen mode Exit fullscreen mode

Lalu jalankan pengujian sesuai tingkat risikonya:

Setiap pull request:
- smoke test
- functional test
- load test ringan untuk endpoint kritis

Sebelum rilis besar:
- load test penuh
- stress test
- soak test

Saat perubahan infrastruktur:
- capacity test ulang
Enter fullscreen mode Exit fullscreen mode

Jalankan load test ringan sebagai bagian dari CI/CD agar regresi muncul sebelum masuk ke produksi.

Simpan pengujian kinerja berdampingan dengan pengujian fungsional. Dengan begitu, setiap perubahan API diperiksa dari dua sisi:

Apakah API benar?
Apakah API cukup cepat?
Enter fullscreen mode Exit fullscreen mode

Keduanya harus menjadi bagian dari definisi “siap rilis”.

Pertanyaan yang sering diajukan

Apa perbedaan antara load testing dan stress testing?

Load testing menguji trafik yang diharapkan dan memastikan API mampu menanganinya. Stress testing mendorong beban melewati trafik tersebut untuk menemukan titik batas dan mode kegagalan.

Singkatnya:

Load testing  = validasi operasi normal
Stress testing = mencari titik gagal
Enter fullscreen mode Exit fullscreen mode

Haruskah melihat waktu respons rata-rata atau persentil?

Gunakan persentil.

Rata-rata bisa menyembunyikan request yang sangat lambat. Persentil ke-95 dan ke-99 menunjukkan pengalaman pengguna yang terkena tail latency, yaitu bagian yang paling sering menyebabkan keluhan.

Dapatkah pengujian kinerja API dilakukan sebelum backend selesai?

Anda bisa menguji kontrak dan desain API lebih awal, tetapi angka latency yang bermakna membutuhkan implementasi dan infrastruktur nyata.

Gunakan server tiruan atau mock server untuk validasi fungsional awal. Jalankan load test terhadap backend nyata saat implementasi sudah tersedia.

Seberapa sering pengujian kinerja harus dijalankan?

Jalankan load test ringan di CI untuk endpoint kritis pada setiap perubahan penting. Jalankan stress test dan soak test penuh sebelum rilis besar.

Kinerja biasanya menurun perlahan dan tidak selalu terdeteksi oleh pengujian fungsional. Pemeriksaan rutin lebih aman daripada satu pengujian besar tepat sebelum peluncuran.

Top comments (0)