Bicara tentang JMeter? Kemungkinan besar, jika Anda berada di subjek, maka Anda sudah membaca segala sesuatu tentang alat ini untuk pengujian stres. Tapi aku punya sesuatu yang mengejutkanmu. Selama tiga tahun di QA, saya menyadari bahwa JMeter sangat fleksibel dan dapat digunakan untuk berbagai keperluan. Misalnya, untuk:
- mencari bug yang sulit dipahami dengan jatuhnya situs untuk beberapa pengguna;
- pemanasan cache cepat di ribuan halaman produk;
- menguji backend aplikasi seluler;
- membuat 2000 catatan dengan data pengguna dalam database aplikasi dalam waktu singkat.
Jika Anda tertarik, selamat datang di kucing. Ternyata dengan lantang, jadi saya akan memecah artikel menjadi dua bagian.
Penafian: Untuk alasan yang jelas, saya tidak memasukkan tangkapan layar dari proyek nyata ke dalam artikel (atau mengekstrak semua informasi penting dari mereka). Ilustrasi diberikan hanya untuk tujuan penelitian dan pendidikan.
Aplikasi JMeter Klasik
JMeter - applet Java dengan GUI. Untuk pengujian, ini dimulai tanpa antarmuka grafis. Dan untuk menulis skrip uji, ia memiliki panel di mana Anda dapat melakukan apa saja.
Beginilah proses pembuatan skrip terlihat (bahkan kata "menulis" tidak cocok)Rencana Uji umum dibuat, di mana Grup Thread melemparkan dirinya sendiri dengan elemen-elemen utama pengujian: pengontrol dan permintaan proses (HTTP, FTP, dll.).
Selain itu, ada elemen tambahan untuk pengaturan parameter. Misalnya, Default Permintaan HTTP memungkinkan Anda menentukan server utama, tajuk dan mengaktifkan / menonaktifkan unduhan aset tambahan (gambar, gaya, font, dll.). Sangat mudah untuk mengetahuinya. Dan Anda dapat langsung menjalankan tes dari antarmuka ini dan melihat hasilnya.
JMeter dapat merekam kasus uji tersebut. Ini berjalan sebagai proxy pada mesin lokal dan, jika Anda mengkonfigurasi browser (atau aplikasi), mengarahkan lalu lintas melalui proxy ini, JMeter akan mencatat semua permintaan dan tanggapan. Dan dari set ini, Anda dapat membuat skrip uji yang akan mengulangi tindakan pengguna, dan menjalankannya di mana pun dan kapan pun Anda inginkan:
Masalah utama adalah tumpukan memori Java itu sendiri. Itu terletak di langit-langit dan dapat jatuh dengan 50 utas pengujian simultan, bahkan pada mesin kelas atas.
Jika mesin tidak memiliki daya yang cukup untuk pengujian beban penuh, hubungi organisasi pihak ketiga. Mereka mengerahkan infrastruktur yang merupakan satu set server. Mereka mendapat JMeter yang sama. Dengan bayaran, orang-orang ini akan menjalankan skrip Anda pada beban apa pun. Kami melamar layanan seperti itu di Octoperf dan Blazemeter.
Ini sepak bola, sayang: bagaimana kami menangkap bug dengan kerusakan sebagian server
Kami telah terlibat dalam pengembangan web selama 18 tahun (sorakan - sekarang Anda bisa merokok, menikah, dan menonton John Wick). Ada banyak pelanggan seumur hidup mereka, tetapi yang terbesar baru-baru ini muncul. Misalnya, kami membuat situs di
Sitecore untuk salah satu klub sepak bola Liga Premier Inggris dengan paradigma SPW (situs web satu halaman: semua halaman terbuka tanpa memuat ulang halaman browser itu sendiri). Di bawah tenda adalah panel admin untuk mengelola halaman pertandingan langsung. Ini adalah siaran online tekstual dari permainan: acara utama (gol, penghapusan, tendangan bebas) dimuat secara otomatis dari sistem Opta, dan foto, komentar, dan kiriman ulang penggemar dari Twitter dan Instagram diterbitkan oleh orang-orang langsung - manajer konten klub sepakbola.
Saya akan mencatat dengan bangga: setelah rilis, media Inggris menerbitkan artikel di bawah judul seperti "Akhirnya, hegemoni situs-situs lama klub sepak bola berakhir." Saat itu, sebagian besar klub sudah memiliki situs. Tetapi mereka tampak seperti dikembangkan pada awal tahun 2000-an dan tidak berubah sejak saat itu - dengan desain dan UX yang sesuai.
Sebelum diluncurkan, kami melakukan uji beban penuh dan memastikan semuanya berjalan sebagaimana mestinya. Struktur server terlihat seperti ini:
- permintaan dari klien masuk ke server load balancing β
- server load balancing memeriksa status delapan server CD β
- server load balancing mengirimkan permintaan ke server CD yang paling sedikit dimuat β
- Server CD merespons klien.
Setahun setelah peluncuran, selama gelombang besar pengguna ke situs, klien menelepon dan mengatakan bahwa situs itu turun:
- Situs kami tidak berfungsi! Tidak berfungsi sama sekali! Hanya layar putih dan tulisan dari browser yang situsnya rusak! - kata klien.
Kami panik membuka situs, dan dengan itu semuanya OK:
"Masih bekerja," jawab kami.
Klien membuka situs dari telepon dan komputer dan ... semuanya baik-baik saja!
- Sungguh, maaf. Tampaknya, pengguna memiliki masalah.
Pesan tersebut tidak muncul dari awal, jadi kami melakukan penelitian: kami meluncurkan utilitas untuk memantau status server Server Density dan melihat apa yang terjadi pada mereka selama masuknya pengguna di situs:
Ada beban, tetapi semua server CD terlihat hampir samaSegera cerita itu terulang kembali - beberapa pengguna melaporkan situs yang benar-benar rusak. Itu bukan semacam kesalahan atau halaman tidak ditemukan - server tidak menanggapi permintaan. Itu mungkin untuk menangkap situasi dengan bantuan JMeter.
Tujuannya sederhana - muat delapan server dan lihat apa yang terjadi. Tes stres dilakukan ketika fajar terjadi di Chelyabinsk, dan di London itu adalah malam yang dalam. Kami menggunakan beberapa mesin dalam mode non-antarmuka (memungkinkan Anda menjalankan lebih banyak utas pada saat yang bersamaan). Script tanpa henti membuka halaman utama, dan ini adalah kesalahan utama kami.
Kami mengunduh aset yang sama yang sudah di-cache ratusan kali. Karena itu, beban keluar tidak signifikan. Kemudian muncul ide: di situs - kereta dan gerobak kecil halaman dengan berita untuk tanggal tertentu. Jika Anda memajukan beberapa variabel dan menggantinya di URL, kami akan selalu mendapatkan halaman acak (misalnya - ... url / news / 2016/08/23 /? Halaman = 4).
Tiba-tiba, kami menyadari bahwa Server Density memiliki beberapa βperataanβ bawaan dalam grafik beban server selama periode sebelumnya. Jika dalam lima menit beban pada server mencapai 100%, kemudian turun menjadi 0%, dan setelah 20-30 detik meningkat menjadi 90%, itu akan menunjukkan nilai rata-rata untuk periode ini - sekitar 80-90%. Karena itu, kami tidak melihat kerusakan server nyata.
Setelah memeriksa log secara terperinci selama stress test, kami menemukan bahwa salah satu server-CD masuk ke reboot pada 100% beban dan tidak memberi tahu siapa pun tentang hal itu (ia sangat tertutup).
Penyeimbang beban hanya melihat pemanfaatan CPU dari semua server. Dia melihat bahwa salah satu dari mereka dimuat di 20%, dan sisanya di 90%, dan mengirim pengguna ke yang pertama. Dan dia dalam reboot dan membagikan layar putih. Selain itu, server distribusi mengekspos pengguna ke cookie dan mengikatnya dengan erat ke server idle. Karena itu, bahkan setelah pembaruan, situs tidak tersedia. 7 dari 8 pengguna yang tersisa pada saat yang sama menikmati hidup dan mengatakan bahwa semuanya berfungsi.
Kesimpulan:
kami menemukan bahwa JMeter dapat digunakan untuk stress test dan pada saat yang sama menganalisis status server selama pengujian dengan alat lain. Kami berhasil "menangkap" masalah dengan jatuhnya situs di antara beberapa pengguna dan menyelesaikannya dengan memperbaiki logika distribusi muatan dan menambahkan kontrol keadaan.
Di bagian selanjutnya saya akan memberi tahu Anda bagaimana, dengan bantuan JMeter, kami menyiapkan proses caching untuk halaman produk, menguji pengoperasian aplikasi seluler tanpa aplikasi itu sendiri dan menciptakan 2.000 pengguna dalam sistem tanpa akses ke database.