Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Jenis uji beban

Jenis tes berikut didasarkan pada pertanyaan dasar yang tercantum sebelumnya dalam panduan ini.

Berapa banyak beban yang dapat ditahan aplikasi saya?

Saat menyiapkan pengujian untuk menentukan beban yang dapat ditahan aplikasi Anda, pertama-tama putuskan apakah Anda ingin mengukur permintaan per detik (req/s), waktu respons (detik), atau pengguna bersamaan. Untuk kedua kasus tersebut, tentukan bagian mana dari aplikasi yang diuji.

Tentukan ambang batas yang dapat diterima untuk kinerja dan tingkat kesalahan sistem target Anda. Untuk beberapa sistem, Anda mungkin tidak peduli dengan waktu respons selama acara berhasil diproses. Untuk banyak aplikasi, seperti yang memiliki interaksi pengguna, tentukan batasan untuk apa yang dapat diterima oleh pengguna akhir.

Hal ini sering membantu untuk melakukan tes dalam langkah-langkah. Beban ditingkatkan dengan setiap langkah sampai Anda mencapai ambang batas yang ditentukan. Untuk tes berulang, Anda dapat belajar dari tes sebelumnya dan meningkatkan langkah Anda untuk melakukan lebih sedikit langkah dalam tes dan masih mendapatkan hasil yang valid.

Dapatkah aplikasi saya menangani beban X?

Mirip dengan pengujian sebelumnya, beban dalam pengujian ini dapat didefinisikan sebagai req/s atau sebagai pengguna bersamaan, tergantung pada sifat aplikasi yang Anda uji. Tes ini adalah versi sederhana dari yang sebelumnya. Di sini, beban kerja tertentuharus diserahkan, dan sistem harus dapat menanganinya. Sangat penting untuk memilih alat pengujian yang mendukung menentukan volume beban yang Anda butuhkan.

Waktu untuk menjalankan tes juga bisa relevan. Beberapa efek dapat diamati hanya ketika tes dijalankan dalam jangka waktu yang lebih lama. Misalnya, tekanan balik dapat menyebabkan antrian kelebihan beban. Jika Anda ingin mereplikasi sistem produksi dan menarik kesimpulan yang valid, waktu yang dibutuhkan untuk menjalankan pengujian dapat memengaruhi ukuran sistem pengujian.

Apakah aplikasi saya secara otomatis naik dan turun?

Elastisitas adalah titik penjualan utama cloud, dan ini adalah sumber utama pengurangan biaya. Menguji apakah aplikasi Anda melakukan penskalaan dengan benar, sehingga Anda dapat dengan percaya diri mendapatkan keuntungan dari elastisitas, harus menjadi bagian dari perjalanan cloud Anda.

Metrik kunci yang digunakan untuk meningkatkan dan menurunkan perlu diidentifikasi. Biasanya, ini adalah beban CPU dari sistem target. Endpoint yang menciptakan beban CPU dapat digunakan sebagai target.

Karena tes ini tidak memerlukan keterwakilan, Anda bisa mendapatkan keuntungan dari penargetan titik akhir yang bebas dari efek samping. Anda juga tidak ingin memulai aliran yang mempertahankan data yang dapat terakumulasi, atau yang memulai proses selanjutnya dan menginduksi biaya yang tidak perlu atau memblokir beban.

Lakukan tes dalam proses bertahap, secara bertahap meningkatkan beban. Interval harus cukup panjang sehingga pada setiap langkah, metrik dapat memulai penskalaan. Misalnya, jika Anda memiliki aturan bahwa beban CPU harus lebih tinggi dari 70 persen selama periode 5 menit, langkah Anda harus lebih lama dari 5 menit untuk menyediakan waktu agar acara penskalaan dimulai dan dijalankan. Anda juga ingin melihat bahwa penskalaan berfungsi dan memperbaiki situasi beban yang Anda buat.

Pertimbangkan untuk memulai tes penskalaan Anda dengan lebih dari satu server. Dalam lingkungan kecil, penskalaan bisa lambat dan membutuhkan beberapa siklus untuk mengatasi beban. Dan kluster EC2 Auto Scaling hanya dapat berlipat ganda ukurannya. Ini berarti bahwa jika Anda memulai dengan satu server dan memulai uji beban, peristiwa penskalaan pertama maksimum hanya dapat berupa dua server. Jika beban yang dihasilkan membutuhkan tiga server, Anda akan memerlukan dua peristiwa penskalaan, yang bisa memakan waktu 20 menit atau lebih.

Pantau pemicu yang diinginkan untuk acara peningkatan skala dan apakah penskalaan sesuai untuk beban aktual.

Jika Anda telah menerapkan acara penurunan skala, Anda juga dapat menguji ini secara bertahap. Pantau apakah penskalaan turun berlaku dan sesuai untuk beban yang ada, dan konfirmasikan bahwa itu tidak memulai penskalaan segera lagi.

Apakah perilaku aplikasi saya menurun seiring waktu dengan beban tinggi yang konstan?

Beberapa efek dapat diamati hanya ketika beban dihasilkan selama periode waktu yang lama. Salah satu efek terpenting adalah tekanan balik. Ini berarti bahwa ketika suatu sistem terlalu lambat untuk memproses jumlah permintaan pada kecepatan yang mereka datangi, kinerja sistem kliennya akan menurun.

Ini lebih mudah diamati jika sistem lambat adalah target beban. Dalam pengaturan yang lebih kompleks, Anda dapat mengamati efeknya hanya ketika dampak uji beban merambat. Solusi penelusuran yang mampu memvisualisasikan waktu respons antara masing-masing layanan dalam sistem terdistribusi tidak hanya menunjukkan hasil lebih cepat, tetapi dapat membantu mengidentifikasi sistem yang bertindak sebagai hambatan. Anda dapat mengidentifikasi sistem bottleneck dengan mendapatkan ID korelasi pesan dari file log. Setiap permintaan mempertahankan ID yang sama di semua sistem yang melalui uji beban.

Menggunakan ID korelasi membantu Anda melacak seluruh perjalanan satu pesan melalui semua komponen yang berbeda di platform Anda. Dengan informasi ini, Anda dapat menghitung waktu pemrosesan untuk setiap komponen tunggal yang dilalui pesan Anda (processing_time = departure_time — arrival_time) dan mengidentifikasi yang paling lambat. Zipkin, Jaeger, dan AWS X-Raymerupakan solusi terkemuka di ruang ini.

Untuk hasil yang paling andal, pilih alat yang mendukung pengaturan tingkat permintaan konstan. Ini berarti bahwa jika sistem target semakin lambat, konkurensi alat uji harus meningkat dari menjaga req/s konstanta. Ketika sistem mulai merespons lebih lambat, itu akan mengikat lebih banyak utas dan menurunkan tingkat permintaan alat penghasil beban Anda. Alat dengan tingkat permintaan konstan harus meningkatkan konkurensi ketika terjadi, dan Anda akan melihat kegagalan lebih cepat. Alih-alih mengukur degradasi dengan persyaratan yang dicapai, Anda akan mengukur berdasarkan latensi dan bahkan permintaan yang gagal.

Apakah aplikasi saya berfungsi?

Biasanya, Anda tidak akan membuat beban tinggi melainkan sejumlah permintaan yang masuk akal yang memverifikasi fungsionalitas. Anda juga dapat melakukan ini secara berkala terhadap produksi, ketika pelanggan tidak mengunjungi arus yang diuji, untuk memiliki lapisan pemantauan lain.

Sebagai jalan pintas, skenario yang sudah dibuat untuk pengujian beban dapat digunakan kembali pada produksi dengan beban yang lebih rendah yang dikonfigurasi.