Sebuah API dapat melewati setiap pengujian fungsional dan masih gagal dalam produksi. API tersebut mengembalikan data yang benar, dengan kode status yang benar, sesuai dengan skema yang benar, dan kemudian gagal saat seribu pengguna mengaksesnya secara bersamaan. Pengujian fungsional memberi tahu Anda bahwa API itu benar. Pengujian kinerja memberi tahu Anda bahwa API itu benar dan cukup cepat untuk bertahan dari lalu lintas nyata.
Panduan ini menjelaskan apa itu pengujian kinerja API, jenis pengujian yang penting, metrik yang perlu diperhatikan, dan cara menjalankan pengujian kinerja langkah demi langkah di Apidog.
Apa itu pengujian kinerja API
Pengujian kinerja API mengukur bagaimana suatu API berperilaku di bawah beban: seberapa cepat responsnya, berapa banyak permintaan yang dapat ditangani, dan pada titik mana ia mengalami penurunan atau kegagalan. Ini bukan tentang apakah responsnya benar; itu adalah pengujian fungsional. Ini tentang apakah respons tiba dengan cepat dan andal saat sistem berada di bawah tekanan.
Tujuannya adalah untuk menemukan batasan sebelum pengguna Anda menemukannya. Setiap API memiliki batas atas, sebuah titik di mana waktu respons meningkat, kesalahan muncul, atau layanan berhenti merespons. Pengujian kinerja menemukan batas atas tersebut dalam lingkungan yang terkontrol sehingga Anda dapat meningkatkannya, merencanakan kapasitas di sekitarnya, atau setidaknya mengetahui keberadaannya.
API adalah target yang baik untuk pengujian kinerja karena bersifat deterministik dan cepat untuk dipanggil. Tidak ada peramban untuk dirender, tidak ada UI untuk ditunggu. Anda mengirim permintaan, Anda mengukur respons. Hal itu membuat pengujian kinerja API lebih murah untuk dijalankan dan lebih stabil dibandingkan pengujian beban end-to-end yang lengkap.
Jenis-jenis pengujian kinerja
“Pengujian kinerja” adalah istilah umum. Di bawahnya terdapat beberapa jenis pengujian yang berbeda, masing-masing menjawab pertanyaan yang berbeda.
Pengujian beban (Load testing) menerapkan lalu lintas yang Anda harapkan, volume permintaan normal dan puncak Anda, dan mengonfirmasi bahwa API menanganinya dalam waktu respons yang dapat diterima. Ini adalah pengujian dasar yang pertama kali dijalankan oleh sebagian besar tim.
Pengujian stres (Stress testing) mendorong melampaui lalu lintas yang diharapkan, meningkatkan beban hingga API menurun atau gagal. Tujuannya adalah untuk menemukan titik batas dan melihat bagaimana API tersebut rusak. Apakah melambat secara anggun, ataukah mengembalikan kesalahan dan kehilangan data?
Pengujian lonjakan (Spike testing) menerapkan lonjakan lalu lintas yang tiba-tiba dan tajam, seperti yang dihasilkan oleh obral kilat atau momen viral, dan memeriksa apakah API menyerapnya atau runtuh. Sistem yang menangani beban stabil masih bisa gagal dalam lonjakan.
Pengujian rendam (Soak testing), juga disebut pengujian daya tahan, menahan beban sedang untuk jangka waktu yang lama, berjam-jam atau berhari-hari, untuk mengungkap masalah lambat: kebocoran memori, penipisan kumpulan koneksi, file log yang memenuhi disk. Ini tidak pernah muncul dalam pengujian beban lima menit.
Pengujian asap (Smoke testing) adalah pemeriksaan awal yang ringan: beban kecil untuk memastikan API dan penyiapan pengujian berfungsi sebelum Anda berkomitmen pada pengujian yang panjang dan mahal.
Sebagian besar tim membutuhkan pengujian beban, stres, dan rendam sebagai minimal. Pengujian lonjakan penting jika lalu lintas Anda bersifat terputus-putus.
Metrik yang penting
Pengujian kinerja menghasilkan angka. Ini adalah yang harus dibaca.
Waktu respons adalah berapa lama waktu yang dibutuhkan API untuk menerima, memproses, dan mengembalikan permintaan. Lihat persentil, bukan hanya rata-rata. Rata-rata mungkin terlihat sehat sementara persentil ke-95 dan ke-99, 5% dan 1% permintaan paling lambat, tidak dapat diterima. Pengguna nyata merasakan bagian yang lambat (tail).
Throughput adalah jumlah permintaan yang diselesaikan API per detik. Ini memberi tahu Anda kapasitas nyata sistem, terlepas dari berapa banyak pengguna yang terhubung.
Pengguna bersamaan (Concurrent users) atau pengguna virtual adalah berapa banyak pemanggil simultan yang disimulasikan oleh pengujian. Kapasitas sering kali dinyatakan sebagai konkurensi maksimum yang dipertahankan API sebelum waktu respons melewati anggaran Anda.
Tingkat kesalahan (Error rate) adalah persentase permintaan yang gagal di bawah beban. API yang tetap cepat tetapi mulai mengembalikan kode 500 pada konkurensi tinggi tetap dianggap gagal dalam pengujian.
Pemanfaatan sumber daya (Resource utilization), CPU dan memori pada server, memberi tahu Anda mengapa kinerja menurun. Jika waktu respons meningkat sementara CPU mencapai 100%, Anda terikat pada komputasi (compute-bound); jika CPU menganggur tetapi latensi meningkat, hambatan (bottleneck) ada di tempat lain, seringkali pada basis data atau panggilan ke sistem hilir.
Laporan kinerja yang baik mengaitkan ini bersama: pada konkurensi ini, throughput mencapai puncaknya, waktu respons persentil ke-95 adalah sekian, dan tingkat kesalahan adalah sekian.
Cara menjalankan pengujian kinerja API di Apidog
Apidog menyertakan pengujian beban yang terintegrasi dalam ruang kerja yang sama tempat Anda merancang dan menguji fungsionalitas API Anda, sehingga Anda tidak memerlukan alat terpisah untuk memulai.
Langkah 1: Pilih endpoint atau skenario yang akan diuji. Pilih satu endpoint kritis, atau skenario pengujian multi-langkah yang mencerminkan alur pengguna nyata, seperti login diikuti dengan pengambilan data. Menguji alur yang realistis memberikan angka yang lebih jujur daripada membebani satu endpoint secara terpisah.
Langkah 2: Pastikan lulus pengujian fungsional terlebih dahulu. Jalankan permintaan dengan asertasi-nya sekali. Tidak ada gunanya melakukan pengujian beban pada endpoint yang mengembalikan data yang salah; perbaiki kebenaran sebelum mengukur kecepatan.
Langkah 3: Konfigurasi beban. Tetapkan jumlah pengguna virtual dan durasi pengujian. Apidog memungkinkan Anda meningkatkan beban secara bertahap, mensimulasikan pengguna yang bergabung seiring waktu daripada sekaligus, yang menghasilkan gambaran yang lebih realistis dan membantu menentukan tingkat konkurensi di mana kinerja berubah.
Langkah 4: Jalankan pengujian. Apidog mengeksekusi beban dan melaporkan secara langsung: waktu respons, throughput, tingkat kesalahan, dan bagaimana setiap metrik berubah seiring peningkatan konkurensi. Perhatikan titik infleksi di mana waktu respons mulai meningkat lebih cepat daripada beban.
Langkah 5: Baca hasilnya dan temukan hambatan. Jika waktu respons persentil ke-95 melewati anggaran Anda pada 300 pengguna bersamaan, itu adalah batas atas Anda saat ini. Periksa silang dengan CPU dan memori server untuk memahami penyebabnya. Jalankan kembali setelah perbaikan untuk mengonfirmasi bahwa batas atas telah bergeser.
Langkah 6: Untuk kebutuhan yang lebih berat, ekspor ke JMeter. Ketika Anda membutuhkan pembuatan beban terdistribusi di luar satu mesin, Apidog dapat mengekspor skenario ke JMeter, sehingga Anda mempertahankan definisi pengujian yang sama sambil menskalakan sumber beban.
Unduh Apidog untuk menjalankan pengujian beban pertama Anda terhadap endpoint yang sudah Anda miliki.
Membaca hasil kinerja nyata
Angka tanpa interpretasi adalah kebisingan. Ambil contoh konkret: Anda melakukan pengujian beban GET /products dengan pengguna virtual yang meningkat dari 0 menjadi 500 selama lima menit.
Untuk 200 pengguna pertama, waktu respons persentil ke-95 tetap stabil sekitar 180 ms dan throughput meningkat seiring dengan beban. Ini adalah zona sehat; API mampu mengimbangi. Pada sekitar 280 pengguna, waktu persentil ke-95 mulai meningkat, 240 ms, lalu 400 ms, lalu 900 ms, sementara throughput mendatar alih-alih naik. Pendataran itulah sinyalnya: API telah mencapai batas atasnya. Menambahkan lebih banyak pengguna sekarang menghasilkan respons yang lebih lambat, bukan pekerjaan yang lebih banyak diselesaikan. Setelah 420 pengguna, tingkat kesalahan merayap di atas 1% karena permintaan mulai mengalami waktu habis (timeout).
Putusannya konkret. API ini dengan nyaman melayani sekitar 250 pengguna bersamaan dalam anggaran 200 ms. Batas atas praktisnya mendekati 280, dan mulai gagal sekitar 420. Jika Anda mengharapkan lalu lintas puncak 200 pengguna bersamaan, Anda memiliki kelonggaran. Jika Anda mengharapkan 350, Anda memiliki masalah yang harus diperbaiki sebelum peluncuran, bukan setelahnya.
Itulah yang diberikan oleh pengujian kinerja: bukan “lulus” atau “gagal,” tetapi peta yang jelas tentang di mana API merasa nyaman, di mana ia terbebani, dan di mana ia rusak.
Hambatan kinerja API yang umum
Ketika sebuah pengujian mengungkap batas atas, penyebabnya biasanya salah satu dari beberapa biang keladi yang sudah dikenal.
Kueri database yang lambat adalah yang paling umum. Kolom yang tidak terindeks, pola kueri N+1, atau batasan kueri yang hilang membuat endpoint yang cepat menjadi lambat saat volume data atau konkurensi meningkat. Jika latensi meningkat sementara CPU server tetap rendah, curigai database terlebih dahulu.
Panggilan eksternal yang memblokir menyeret kecepatan endpoint ke kecepatan ketergantungan terlambatnya. API yang memanggil penyedia pembayaran atau layanan pihak ketiga secara sinkron akan mewarisi latensi dan gangguan layanan tersebut.
Penipisan kumpulan koneksi (Connection pool exhaustion) muncul di bawah beban yang berkelanjutan: API kehabisan koneksi database atau klien HTTP dan permintaan mengantre menunggu. Ini adalah temuan pengujian rendam klasik.
Serialisasi yang tidak efisien dari payload respons besar menghabiskan CPU. Mengembalikan lebih banyak data daripada yang dibutuhkan klien membuat setiap respons lebih lambat untuk dibangun dan lebih lambat untuk ditransfer.
Pengujian kinerja menunjukkan di mana batas atasnya; memadukannya dengan metrik sisi server memberi tahu Anda mengapa.
Membangun pengujian kinerja ke dalam proses Anda
Pengujian kinerja yang dijalankan sekali sebelum peluncuran besar berguna. Pengujian kinerja yang berjalan secara teratur jauh lebih berharga, karena kinerja menurun secara diam-diam. Kueri database baru, panggilan hilir tambahan, atau kolom yang tidak terindeks masing-masing dapat menambahkan latensi yang tidak diperhatikan oleh pengujian fungsional apa pun.
Tetapkan anggaran waktu respons dan tingkat kesalahan untuk endpoint kritis Anda, dan perlakukan pelanggaran sebagai kegagalan, sama seperti Anda memperlakukan asertasi yang rusak. Jalankan pengujian beban yang lebih ringan sebagai bagian dari CI/CD sehingga regresi muncul pada permintaan penarikan, dan cadangkan pengujian stres dan rendam yang berat untuk pengujian pra-rilis terjadwal.
Jaga pengujian kinerja berdampingan dengan pengujian fungsional. Ketika keduanya hidup berdampingan, setiap perubahan API diperiksa untuk kebenaran dan kecepatan, dan "ini berfungsi" serta "ini berfungsi cukup cepat" berhenti menjadi pertanyaan terpisah yang mudah dilupakan.
Pertanyaan yang sering diajukan
Apa perbedaan antara pengujian beban (load testing) dan pengujian stres (stress testing)? Pengujian beban menerapkan lalu lintas yang Anda harapkan dan mengonfirmasi bahwa API menanganinya. Pengujian stres mendorong melampaui itu untuk menemukan titik batas. Pengujian beban memverifikasi operasi normal; pengujian stres memetakan mode kegagalan.
Haruskah saya melihat waktu respons rata-rata atau persentil? Persentil. Rata-rata menyembunyikan ekor yang lambat. Persentil ke-95 dan ke-99 menunjukkan apa yang sebenarnya dialami oleh pengguna Anda yang paling tidak beruntung, dan itulah yang mendorong keluhan.
Dapatkah saya melakukan pengujian kinerja API sebelum backend selesai? Anda dapat menguji kontrak dan desainnya, tetapi angka latensi yang bermakna memerlukan infrastruktur nyata. Gunakan server tiruan (mock server) untuk pekerjaan fungsional awal, dan jalankan pengujian beban terhadap implementasi nyata.
Seberapa sering pengujian kinerja harus dijalankan? Jalankan pengujian beban ringan di CI pada setiap perubahan pada endpoint kritis, dan pengujian stres dan rendam penuh sebelum setiap rilis besar. Kinerja menurun secara diam-diam, jadi pemeriksaan rutin lebih baik daripada satu kali pengujian besar sebelum peluncuran.