Anda ingin tahu apa yang terjadi pada API Anda ketika 80 orang melakukan checkout secara bersamaan. Jadi Anda membuka Locust, dan hal pertama yang diminta adalah menulis kelas Python. Mendefinisikan HttpUser. Mendekorasi metode dengan @task. Membangun locustfile.py, menyiapkan lingkungan virtual, memasang beberapa dependensi, lalu mencari tahu mengapa token otentikasi Anda tidak digunakan kembali di seluruh permintaan. Semua itu bukan inti pengujian. Itu adalah biaya masuk sebelum pengujian dimulai.
Locust adalah alat yang bagus, dan desain yang mengutamakan kode adalah intinya. Tetapi jika tujuan Anda adalah jawaban langsung untuk "apakah endpoint login saya bertahan dengan 100 pengguna bersamaan," menulis dan memelihara kerangka kerja Python adalah pekerjaan yang melelahkan untuk satu angka. Ada jalur yang lebih cepat ketika permintaan API yang ingin Anda uji sudah ada di klien API. Dengan Apidog, Anda mengarahkan pengujian kinerja ke skenario pengujian yang ada, mengatur jumlah pengguna virtual dan durasi, dan membaca throughput, waktu respons, dan tingkat kesalahan dari grafik langsung. Tanpa locustfile, tanpa pip install, sama sekali tanpa Python.
Apa yang sebenarnya Locust lakukan dengan baik
Locust adalah alat pengujian beban sumber terbuka yang ditulis dalam Python, dan ia bagus dalam apa yang dibangun untuknya. Anda menggambarkan perilaku pengguna sebagai kode. Pengguna virtual adalah kelas Python, dan hal-hal yang dilakukan pengguna tersebut adalah metode yang Anda tandai sebagai tugas. Berikut adalah bentuk kanonis dari locustfile.py:
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
Anda menjalankannya dengan locust -f locustfile.py, membuka UI web di localhost:8089, mengatur jumlah pengguna dan laju spawn, dan melihat angka-angka meningkat. Karena perilakunya adalah kode, Anda mendapatkan kekuatan ekspresif yang nyata. Logika kondisional, distribusi tugas berbobot, perjalanan pengguna sekuensial, klien kustom untuk protokol di luar HTTP, berbagi status antar permintaan. Pembobotan @task(3) berbanding @task(1) di atas berarti browsing terjadi tiga kali lebih sering daripada menambahkan ke keranjang, yang merupakan jenis realisme yang tidak dapat ditangkap oleh daftar permintaan datar.
Locust juga dapat diukur secara horizontal. Jalankan secara terdistribusi di beberapa proses atau mesin worker dan satu master mengoordinasikannya, sehingga Anda dapat melampaui apa yang dapat dihasilkan oleh satu kotak. Ini digerakkan oleh peristiwa di bawah kap, sehingga setiap worker menampung ribuan pengguna bersamaan tanpa satu thread per pengguna yang memakan memori. Untuk tim yang sudah hidup di Python, memperlakukan pengujian beban mereka sebagai kode yang terkontrol versi, dan perlu memodelkan perilaku pengguna multi-langkah yang kompleks, Locust adalah pilihan yang kuat. Semua itu tidak diperdebatkan.
Biayanya adalah kode. Setiap pengujian adalah program yang Anda tulis, debug, dan pelihara. Jika API Anda berubah, locustfile juga berubah. Jika seorang insinyur baru perlu menjalankan pengujian, mereka membutuhkan lingkungan Python yang cocok. Dan jika Anda belum menulis Python, bahasa itu sendiri menjadi prasyarat untuk menjawab pertanyaan yang tidak ada hubungannya dengan Python.
Di mana model 'code-first' menjadi gesekan
Gesekan muncul di tiga tempat.
Pertama, pengaturan. Sebelum Anda mengukur apa pun, Anda menginstal Python, membuat lingkungan virtual, pip install locust, dan menulis kerangka kerjanya. Untuk pemeriksaan cepat "bisakah endpoint ini menangani 50 pengguna", itu lebih banyak "perpipaan" daripada "payload".
Kedua, duplikasi. Anda mungkin sudah memiliki permintaan-permintaan ini yang didefinisikan di suatu tempat. Mungkin di Postman, mungkin di file .http, mungkin di klien API yang tim Anda gunakan setiap hari. locustfile menggambarkan ulang permintaan yang sudah ada, termasuk alur otentikasi, header, badan permintaan. Sekarang Anda memelihara dua salinan dari pengetahuan API yang sama, dan keduanya mulai menyimpang.
Ketiga, orang-orang yang membutuhkan jawabannya. Seorang insinyur QA, seorang manajer produk yang cemas menjelang peluncuran, atau pengembang frontend yang hanya ingin tahu apakah API bertahan dari email pemasaran, semuanya membutuhkan hasil pengujian beban. Mereka tidak selalu perlu membaca atau menulis Python untuk mendapatkannya. Ketika pengujian terkunci di balik locustfile, jawabannya terkunci di balik satu set keterampilan.
Jika pengujian beban Anda benar-benar membutuhkan logika percabangan dan klien protokol kustom, gesekan itu sepadan dan Locust adalah alat yang tepat. Untuk kasus umum "jalankan permintaan API nyata saya di bawah beban bersamaan dan tunjukkan angka-angkanya," patut dipertanyakan apakah lapisan Python memberikan manfaat apa pun.
Pendekatan Apidog: uji beban permintaan yang sudah Anda miliki
Apidog mendekati pengujian beban dari arah lain. Anda tidak menulis skrip yang menjelaskan permintaan. Anda mengambil permintaan yang sudah Anda buat dan menjalankannya di bawah beban. Unit pengujian beban adalah skenario pengujian, yang hanyalah serangkaian permintaan API yang berurutan dengan lingkungan, variabel, dan pernyataan yang sudah terlampir. Jika Anda telah menggunakan Apidog untuk menguji atau mendebug sebuah endpoint, permintaan tersebut sudah ada. Pengujian kinerja menggunakannya kembali.
Berikut adalah alur lengkapnya.
- Buka skenario pengujian yang ingin Anda uji bebannya. Ini adalah skenario yang sama yang akan Anda jalankan sebagai pengujian fungsional normal, dengan permintaan yang sama dan variabel lingkungan yang sama.
- Pilih untuk menjalankannya sebagai pengujian kinerja alih-alih satu kali.
- Atur jumlah pengguna virtual. Apidog mendukung hingga 100 pengguna virtual, masing-masing melakukan loop melalui setiap permintaan dalam skenario secara paralel selama seluruh pengujian.
- Atur durasi pengujian. Itu adalah berapa lama pengguna virtual terus berulang.
- Atur durasi ramp-up jika Anda ingin peningkatan bertahap. Selama X menit pertama, Apidog secara bertahap membawa pengguna online alih-alih sekaligus; atur ke 0 dan setiap pengguna virtual segera dimulai.
- Jika skenario Anda didorong oleh data, pilih mode pencocokan. "Random Match" membuat setiap pengguna virtual menarik baris acak dari data pengujian Anda di setiap putaran; "Sequential Match" berjalan melalui baris secara berurutan.
- Mulai pengujian dan perhatikan panel langsung.
Grafik diperbarui secara real time. Untuk setiap API dalam skenario, Anda mendapatkan Total Permintaan, Rata-rata Throughput, Rata-rata Waktu Respons, Waktu Respons Maksimum dan Minimum, dan Kesalahan. Arahkan kursor ke grafik untuk melihat angka-angka untuk irisan waktu tertentu. Tab "Kesalahan" menguraikan permintaan yang gagal sehingga Anda dapat melihat endpoint mana yang mulai bermasalah dan kapan. Ketika eksekusi selesai, tab "Laporan Pengujian" menyimpan riwayat sehingga Anda dapat membandingkan eksekusi hari ini dengan minggu lalu setelah Anda mengirim perubahan.
Intinya adalah tidak ada locustfile untuk ditulis dan tidak ada lingkungan Python untuk dikelola. Permintaan yang sama yang melewati pengujian fungsional Anda adalah permintaan yang menghasilkan beban. Itulah perbedaan antara menjelaskan pengujian beban dan menjalankannya. Apidog adalah platform API all-in-one, sehingga desain, debugging, pengujian fungsional, dan pengujian beban sebuah endpoint semuanya terjadi terhadap satu definisi endpoint tersebut.
Perbandingan konkret
Misalnya Anda ingin mengkonfirmasi bahwa endpoint login menangani 100 pengguna bersamaan selama dua menit, dengan ramp-up 30 detik.
Di Locust, Anda menulis kelas pengguna dengan tugas yang memposting kredensial, menangani token yang dikembalikan respons, menyimpannya untuk panggilan lanjutan apa pun, menyimpan file, memulai locust -f login_test.py, membuka UI web, dan memasukkan 100 pengguna, laju spawn, dan waktu berjalan. Jika penanganan token salah, Anda melakukan debug Python sebelum Anda melakukan debug API Anda.
Di Apidog, Anda membuka skenario pengujian login yang sudah Anda buat, mengubahnya ke pengujian kinerja, mengetik 100 untuk pengguna virtual, 2 menit untuk durasi, 30 detik untuk ramp-up, dan memulainya. Otentikasi yang sudah berfungsi di pengujian fungsional Anda masih berfungsi, karena ini adalah skenario yang sama. Anda membaca kurva waktu respons dan tingkat kesalahan saat itu terjadi.
Keduanya tiba pada jenis jawaban yang sama. Salah satu meminta Anda untuk menulis dan memelihara program terlebih dahulu. Yang lain menggunakan kembali apa yang sudah Anda miliki. Untuk perjalanan pengguna yang kompleks dan dimodelkan dengan kode, program itu sepadan. Untuk "apakah endpoint saya cepat dan stabil di bawah beban," penggunaan kembali menang dalam hal waktu.
Batasan jujur di kedua sisi
Jadilah jernih tentang trade-off, karena memilih alat yang salah akan membuang waktu seharian bagaimanapun juga.
Pengujian kinerja Apidog mencapai puncaknya pada 100 pengguna virtual dari satu kali eksekusi, dan beban dihasilkan dari mesin Anda yang menjalankan aplikasi. Jika Anda perlu mensimulasikan puluhan ribu pengguna atau menghasilkan beban dari beberapa wilayah geografis sekaligus, itu di luar target pengujian kinerja dalam aplikasi, dan pengaturan terdistribusi seperti worker Locust atau kluster penghasil beban khusus adalah pilihan yang tepat. Apidog juga merekam permintaan yang gagal secara statistik daripada menangkap seluruh badan permintaan dan respons untuk setiap kegagalan, sehingga debugging forensik mendalam dari satu panggilan gagal tertentu di tengah beban bukanlah kekuatannya.
Trade-off Locust adalah apa yang dibahas di seluruh artikel ini. Kekuatan berasal dari kode, dan kode adalah biaya yang terus-menerus. Anda memelihara locustfile per skenario, menjaga lingkungan Python tetap ada, dan menerima bahwa siapa pun yang ingin menjalankan pengujian perlu membaca Python untuk memahaminya. Untuk jumlah pengguna virtual yang sangat tinggi dan logika protokol khusus, biaya tersebut memberi Anda sesuatu yang nyata. Untuk pemeriksaan beban API sehari-hari, itu adalah biaya tambahan.
Aturan yang masuk akal: jika Anda dapat menggambarkan pengujian sebagai "jalankan permintaan ini dengan konkurensi ini selama waktu ini," gunakan pengujian kinerja dalam aplikasi. Jika Anda membutuhkan percabangan kondisional, grafik tugas berbobot, klien khusus, atau jumlah pengguna enam digit, gunakan kode. Untuk survei yang lebih luas tentang di mana setiap opsi cocok, lihat rangkuman kami tentang alat pengujian beban teratas dan perbandingan alat pengujian beban khusus API.
Membaca angka yang Anda dapatkan kembali
Pengujian beban hanya berguna jika Anda tahu arti dari keluarannya. Empat metrik membawa sebagian besar bobot.
Throughput (RPS/TPS) adalah permintaan atau transaksi per detik, laju layanan API Anda. Ini adalah batas atas yang dapat ditangani sistem Anda. Jika throughput mendatar saat Anda terus menambah pengguna virtual, Anda telah menemukan titik saturasi.
Waktu respons (latensi) adalah berapa lama setiap permintaan berlangsung. Perhatikan rata-rata, tetapi lebih perhatikan maksimumnya. Rata-rata yang sehat dengan maksimum yang buruk berarti beberapa pengguna mengalami pengalaman buruk meskipun sebagian besar baik-baik saja. Latensi ekor adalah di mana pengguna nyata merasakan penderitaan.
Tingkat kesalahan adalah bagian dari permintaan yang gagal. Pengujian bersih pada beban rendah yang mulai menghasilkan 500-an atau timeout saat pengguna virtual meningkat memberi tahu Anda persis di mana sistem rusak. Titik di mana kesalahan dimulai seringkali lebih menarik daripada angka throughput mentah.
Konkurensi adalah berapa banyak pengguna virtual yang aktif. Di Apidog ini adalah jumlah pengguna virtual yang Anda tetapkan, dan ramp-up mengontrol seberapa cepat Anda mencapainya. Ramp-up penting karena sistem yang menangani 100 pengguna yang dicapai secara bertahap masih bisa tumbang jika semua 100 tiba di detik yang sama.
Jika Anda ingin versi yang lebih mendalam tentang ini, panduan kami untuk pengujian kinerja API membahas metrik, jenis pengujian, dan cara membaca kurva, dan artikel dasar-dasar pengujian kinerja mencakup disiplin yang lebih luas.
Bagaimana ini cocok dengan alat yang sudah Anda bandingkan
Jika Anda pernah menggunakan JMeter, model mentalnya mirip dengan Apidog, karena keduanya memungkinkan Anda mengonfigurasi pengujian beban melalui UI daripada kode. JMeter menukarnya dengan rencana pengujian berbasis XML yang lebih berat dan kurva pembelajaran yang lebih curam; tutorial pengujian beban JMeter kami membahasnya secara detail. Jika Anda telah menjalankan beban melalui Postman's collection runner, Anda telah melihat versi yang lebih ringan dari ide yang sama, dibahas dalam pengujian beban dengan Postman, dan Apidog menambahkan pelaporan kinerja khusus di atas permintaan yang juga dapat Anda gunakan untuk pengujian API tanpa Postman. Apidog berada di antara kesederhanaan tanpa kode yang diinginkan orang dan penggunaan kembali permintaan yang mencegah Anda memelihara kerangka kerja terpisah.
Benang merah di antara semuanya adalah bahwa pengujian beban Anda harus menggunakan kembali pengetahuan API yang sudah Anda kodekan, bukan menduplikasinya dalam bahasa baru. Locust menduplikasinya di Python karena Python adalah kekuatannya. Apidog menggunakan kembali skenario Anda karena penggunaan kembali adalah kekuatannya.
Memulai
Jika permintaan Anda sudah ada di Apidog, Anda dapat menjalankan pengujian kinerja dalam lima menit berikutnya. Buka skenario pengujian, alihkan ke pengujian kinerja, atur pengguna virtual dan durasi, lalu mulai. Jika Anda berasal dari locustfile dan lelah memelihara lapisan Python, bangun kembali skenario sekali di aplikasi dan Anda tidak akan lagi menulis kode pengujian beban untuk endpoint itu.
Unduh Apidog dan arahkan pengujian kinerja ke endpoint yang sudah Anda uji. Anda akan memiliki kurva throughput, latensi, dan tingkat kesalahan sebelum Anda selesai menulis locustfile yang setara. Locust tetap menjadi jawaban yang tepat untuk beban terdistribusi dan model-kode dalam skala besar. Untuk pertanyaan yang sebenarnya ditanyakan oleh sebagian besar pengembang, jalankan permintaan yang sudah Anda miliki.
FAQ
Apakah Apidog merupakan pengganti langsung untuk Locust?
Tidak untuk setiap pekerjaan. Untuk pengujian beban permintaan API hingga 100 pengguna virtual tanpa menulis kode, Apidog menggantikan seluruh alur kerja Locust karena ia menjalankan skenario pengujian Anda yang sudah ada secara langsung. Untuk beban terdistribusi pada jumlah pengguna yang sangat tinggi atau protokol non-HTTP kustom yang dimodelkan dalam kode, Locust masih lebih cocok.
Apakah saya perlu menulis kode apa pun untuk pengujian beban di Apidog?
Tidak. Anda mengkonfigurasi pengguna virtual, durasi pengujian, dan waktu ramp-up di UI, dan pengujian menjalankan permintaan dari skenario pengujian yang sudah Anda buat. Tidak ada locustfile dan tidak ada lingkungan Python yang perlu disiapkan.
Berapa banyak pengguna virtual yang dapat disimulasikan Apidog?
Hingga 100 pengguna virtual dalam satu pengujian kinerja. Masing-masing melakukan loop melalui setiap API dalam skenario secara paralel selama durasi yang Anda tetapkan. Jika Anda membutuhkan lebih banyak dari itu atau beban dari berbagai wilayah, alat berbasis kode terdistribusi seperti Locust adalah pilihan yang tepat.
Metrik apa yang dilaporkan oleh pengujian kinerja Apidog?
Untuk setiap API dalam skenario, Anda mendapatkan Total Permintaan, Rata-rata Throughput, Rata-rata Waktu Respons, Waktu Respons Maksimum dan Minimum, dan Kesalahan, diperbarui secara langsung di grafik. Tab Kesalahan menguraikan permintaan yang gagal, dan tab Laporan Pengujian menyimpan riwayat eksekusi sehingga Anda dapat membandingkan perubahan.
Bisakah saya melakukan pengujian beban dengan permintaan berbasis data?
Ya. Jika skenario Anda didukung oleh data pengujian, pilih "Pencocokan Acak" agar setiap pengguna virtual menarik baris acak di setiap putaran, atau "Pencocokan Berurutan" untuk menelusuri baris secara berurutan.
Apakah saya masih harus menggunakan Locust untuk sesuatu?
Ya, ketika kekuatannya sesuai dengan kebutuhan Anda: perilaku pengguna yang didefinisikan kode dengan percabangan dan tugas berbobot, klien protokol khusus, dan pembangkitan beban terdistribusi yang jauh melebihi 100 pengguna virtual. Gunakan alat yang tepat untuk bentuk pengujiannya.