Kami akan merusak server web dan mengisinya dengan banyak permintaan HTTP. Perlahan-lahan isi semua yang ada di sekitar dengan banjir HTTP dan amati degradasi total. Bersiaplah Azure, tidak akan ada bahan tertawaan!
Jika sedikit lebih serius, saat melakukan lab standar tentang pengenalan Azure sebagai bagian dari AZ-900, Microsoft Azure Fundamentals memutuskan untuk melihat kemampuan salah satu konfigurasi minimum mesin virtual B1 Standar (1 GiB RAM, 1 vCPU).
Di lab standar, server web seperti Apache atau IIS diinstal pada mesin virtual, situs sederhana diluncurkan dan di sinilah semuanya berakhir. Bagi saya, kenalan seperti itu tidak cukup dan menjadi menarik untuk melihat bagaimana server akan menanggapi sejumlah besar permintaan, apa yang akan terjadi dengan waktu respons dan, yang paling penting, apakah mengubah ukuran mesin virtual akan membantu meningkatkan kualitas pekerjaan. Selain itu, untuk menambah kekhawatiran ke server, WordPress (Apache, MySQL, PHP) digunakan pada mesin virtual dengan Ubuntu. Untuk pengujian, skrip Python digunakan yang terus menghasilkan permintaan GET ke alamat yang sama.
Dalam kasus permintaan tunggal, waktu respons server tidak melebihi 300-400 md, yang tampaknya cukup dapat diterima untuk konfigurasi seperti itu.
Hal lainnya adalah bagaimana server akan bereaksi terhadap permintaan massal ketika GET tiba dalam kelompok. Dalam Python, permintaan paralel seperti itu dapat diimplementasikan menggunakan modul "concurrent.futures", yang menyediakan akses ke antarmuka tingkat tinggi untuk panggilan asinkron. Ide implementasi terinspirasi oleh resource creativedata.stream . Akibatnya, untuk pengujian, server diserang oleh gelombang permintaan GET dengan jumlah permintaan simultan yang meningkat secara linier. Untuk kejelasan, waktu respons untuk setiap permintaan dibatasi hingga 10 detik. Untuk setiap percobaan, 5000 permintaan dikirim. Ada batas waktu 3 menit di antara upaya.
Hasil pengujian untuk VM Standard B1s ditunjukkan pada tabel
Jumlah permintaan GET paralel |
Waktu tes |
Waktu respons rata-rata |
Waktu respons maksimum |
Jumlah penolakan |
sepuluh |
246 |
0.482504 |
1.393406 |
0 |
20 |
183 |
0.716227 |
1.775027 |
0 |
30 |
158 |
0.925803 |
2.239563 |
0 |
40 |
133 |
1.028995 |
10.389413 |
4773 |
40 , , “200” 100%.
. . .
, . B1s Standard B2s (4GiB RAM, 2 vCPU). ?
, . 10000.
VM Standard B2s
- GET |
() |
() |
() |
|
20 |
198 |
0.387310 |
1.377070 |
0 |
40 |
171 |
0.660414 |
1.481950 |
0 |
60 |
140 |
0.808657 |
1.674038 |
0 |
80 |
130 |
1.001915 |
2.142157 |
0 |
100 |
119 |
1.163476 |
2.252231 |
0 |
120 |
119 |
1.417223 |
2.703418 |
0 |
140 |
119 |
1.654639 |
2.98774 |
0 |
160 |
119 |
1.901040 |
5.622294 |
0 |
. , . , .
160 5Mb/s .
Ruang untuk kesimpulan
Tes dengan banjir HTTP dan implementasi saat ini tidak berpura-pura menaklukkan ruang dan mengikuti standar emas. Namun, pengujian tersebut menunjukkan hubungan langsung yang diharapkan antara jumlah permintaan serentak dan beban pada CPU, memori, serta waktu respons rata-rata dan maksimum.
Rupanya, server dengan sejumlah besar RAM (4Gb versus 1Gb) mengatasi beban semacam ini dengan lebih baik, dan bahkan dengan peningkatan 5 kali lipat dalam jumlah permintaan (160 versus 30), ia secara teratur merespons dengan 200 OK!
PS
Contoh utilitas uji tersedia di repositori saya di github