Dalam artikel ini kami akan membagikan pengalaman praktis kami sendiri yang kami peroleh saat menguji aplikasi Aplikasi Web (toko online) yang berjalan di cloud MS Azure, serta menjelaskan alat apa yang kami gunakan untuk menyelesaikan masalah ini dan kesimpulan yang dibuat berdasarkan temuan hasil.
Benda uji
Kami memilih VirtoCommerce Storefront (aplikasi web yang digunakan sebagai ujung depan aplikasi yang dibuat pada platform VirtoCommerce) sebagai objek uji.
Untuk mendapatkan gambaran nyata dari kemampuan sistem, kita perlu mensimulasikan permintaan pengguna sedekat mungkin dengan kenyataan. Tidak masuk akal untuk memeriksa halaman utama, yang mungkin ada di cache, dan kemudian mengklaim bahwa kecepatan kami adalah 1 k req / detik. Tidak ada artinya dalam metrik kinerja seperti itu dalam kehidupan nyata.
Oleh karena itu, agar hasil pengujian kami menjadi signifikan secara statistik dan untuk mencerminkan indikator kinerja pada lalu lintas nyata sedekat mungkin, diputuskan untuk menggunakan kueri yang sedekat mungkin dengan perilaku pengguna nyata di toko online.
Marilah kita memikirkan tindakan-tindakan berikut, yang di dalamnya tes "nyata" kita akan terdiri:
Aksi pengguna (tipe uji)
| Persentase dari total permintaan
|
Lihat halaman kategori unik dengan produk-produknya
| 30%
|
Lihat kartu produk unik
| 40%
|
Tambahkan Item ke Troli
| 10%
|
Cari produk dengan kata kunci atau atribut unik
| 20%
|
Fig. 1. Tindakan utama pengguna dan frekuensi penggunaan khusus mereka.Tes persiapan data
Fase terpenting untuk pengujian apa pun adalah persiapan data. Data uji harus dipilih sedemikian rupa sehingga sebanyak mungkin sesuai dengan data dalam sistem nyata, baik secara kuantitas maupun kualitas (komunikasi, struktur, dll.). Jika memungkinkan, jumlah total data harus mencukupi sehingga saat pengujian ada sesedikit mungkin panggilan berulang ke data yang sama, yang akan menghindari seringnya menggunakan cache dan sebagai hasilnya mendapatkan gambaran kinerja sistem yang paling pesimistis.
Data utama untuk toko online, sebagai aturan, adalah: katalog produk dan kategori dengan harga, diskon, dan informasi tentang saldo.
Sebagai pengisian lingkungan pengujian, data katalog nyata digunakan, yang akan digunakan pada lingkungan produksi utama:
Fig. 2. Data digunakan untuk mengisi sistem yang diuji.Jelas bahwa bagi pembaca yang tidak terbiasa dengan struktur katalog VirtoCommerce, beberapa tipe data mungkin tidak berarti apa-apa, tetapi kami akan menyajikannya untuk setidaknya memiliki gagasan tentang urutan kuantitatif.
Tes persiapan dan pencatatan proyek
Sebagai alat utama untuk pengujian beban, kami akan menggunakan MS Visual Studio Enterprise 2017 (edisi studio lain mungkin tidak mendukung jenis proyek ini) dan jenis proyek
Kinerja Web dan Proyek Uji Beban .
Fig. 3. Buat proyek baru.Setelah membuat proyek, kita perlu membuat tes untuk setiap tindakan pengguna yang didefinisikan sebelumnya. Kami membatasi diri untuk membuat tes untuk satu tindakan pengguna sebagai contoh, karena tindakan lainnya dibuat dengan analogi.
Untuk tes, kami akan menggunakan tipe standar tes Web Performance Test, yang dibangun dalam Visual Studio.
Tes pertama yang akan kami buat akan menjadi tes yang mengungkapkan detail produk di toko online.
Untuk membuat tes, pilih jenis tes
"Tes Kinerja Web" dari daftar yang ditawarkan oleh Studio, tetapkan nama
"Storefront-ProductDetail" .
Fig. 4. Memilih jenis tes di Visual Studio.Untuk jenis pengujian ini, Visual Studio akan segera mencoba membuka browser, di mana dimungkinkan untuk secara interaktif mengklik tindakan yang diperlukan secara langsung di situs, tetapi kami tidak akan melakukan ini, tetapi segera tutup browser dan berhenti merekam. Akibatnya, kami mendapatkan tes
Storefront-ProductDetail.webtest kosong.
Selanjutnya, kita perlu menambahkan sumber data untuk tes ini, sehingga kita dapat menggunakan parameter kueri yang berbeda dalam tes yang sama, untuk ini, V
S Studio Web Performance Test memberikan kesempatan seperti itu.
Sebagai sumber data untuk pengujian kami, kami akan menggunakan tabel di database tempat catatan produk disimpan. Setelah itu, kita akan dapat menggunakan data dari sumber yang terhubung dalam permintaan, yang akan membuka detail produk pada aplikasi yang diuji. Ini dicapai dengan memasukkan konstruksi
"{{Nama sumber data. Nama tabel. Nama kolom}}"Akibatnya, setelah semua manipulasi, tes pertama kami akan mengambil formulir ini.
Fig. 5. Isi tesSudah waktunya untuk menjalankan pertama, cobalah untuk menjalankan tes kami dan pastikan itu berfungsi dengan benar.
Fig. 6. Hasil tes tunggalDengan analogi, kami akan membuat tes untuk semua skenario kami yang lain.
Fig. 7. Suite tes yang dihasilkanSetelah itu, hampir semuanya siap untuk membuat tes gabungan yang akan meniru perilaku pengguna yang sebenarnya di situs.
Untuk melakukan ini, tambahkan
LoadTest baru ke proyek kami
.
Gbr. 8. Buat tes beban baruDi wisaya yang muncul, pilih jenis
Tes Beban di tempat .
Fig. 9. Memilih jenis tesItem ini memerlukan beberapa klarifikasi, karena Anda benar bertanya: "Dan apa yang ada di tempat?" Topik artikel ini adalah tentang pengujian menggunakan Layanan Tim dan MS Azure, tetapi ada nuansa, karena kami menggunakan sumber data dalam bentuk tabel atau layanan eksternal lainnya untuk pengujian, ini dapat menyebabkan beberapa kesulitan ketika kami mencoba menjalankan tes ini di cloud.
Setelah upaya yang sia-sia untuk membuat tes seperti itu bekerja di cloud, kami meninggalkan usaha ini dan memutuskan untuk menggunakan apa yang disebut tes "direkam" untuk pengujian, yang diperoleh dengan merekam pertanyaan yang dihasilkan oleh tes yang berjalan secara lokal dan terhubung ke sumber data.
Untuk merekam tes, kami menggunakan Fiddler, yang memiliki kemampuan untuk mengekspor permintaan ke format
Tes Visual Studio Web . Sedikit lebih jauh kami akan menjelaskan secara lebih rinci prosedur untuk merekam tes semacam itu.
Pada langkah berikutnya, kami memilih durasi pengujian, jumlah pengguna dan, yang paling penting, menunjukkan tes mana yang akan terdiri dari
MixedLoadTest kami dan dalam proporsi berapa mereka akan digunakan.
Gbr. 10. Komponen ujiAkibatnya, setelah semua tindakan, kami mendapatkan
MixedLoadTest gabungan yang dikonfigurasi untuk berjalan untuk aplikasi yang digunakan secara lokal.
Selanjutnya, kita perlu menjalankan tes ini dan mencoba untuk merekam dengan
Fiddler semua permintaan yang akan dihasilkan sebagai hasil dari tes, serta mendapatkan "catatan" yang dapat kita jalankan langsung di cloud.
Jalankan
Fiddler pertama kali dan uji
MixedLoadTest kami.
Fig. 11. Hasil tesSetelah memproses semua data, kami mendapatkan gambar ini di Fiddler
Fig. 12. Tes Sesi di FiddlerSelanjutnya, di Fiddler, simpan semua sesi dalam format
Tes Web Visual Studio ,
File -> Sesi ekspor -> Semua sesi -> Tes Web Visual Studio dan tambahkan file yang dihasilkan ke proyek. Biarkan saya mengingatkan Anda bahwa tindakan ini diperlukan agar kami bisa mendapatkan tes tanpa referensi ke sumber data eksternal, karena memulai tes semacam ini dapat menyebabkan masalah di cloud.
Fig. 13. Detail tes "direkam"Sekarang hampir semuanya siap untuk menjalankan pengujian kami di cloud, langkah terakhir dalam mempersiapkan tes adalah membuka
MixedLoadTest yang telah direkam dalam editor teks apa pun dan mengganti
localhost : 8888 (alamat proxy, Fiddler) dengan alamat toko kami di cloud.
Menjalankan tes di cloud
Untuk menjalankan tes di cloud, kami membutuhkan akun yang valid di
Layanan Tim Visual Studio .
Buat LoadTest baru, hanya kali ini pilih
Uji Beban berbasis Cloud dengan Layanan Tim Visual Studio .
Pada langkah berikutnya, kami memilih pusat data dari mana lalu lintas ke sumber daya yang diuji akan dihasilkan, serta jumlah maksimum agen (pengguna) untuk pola konstan, atau jika kami ingin menggunakan peningkatan bertahap dalam beban, kita perlu mengatur parameter yang sesuai.
Pada langkah memilih tes, kami memilih satu-satunya tes yang kami rekam sebelumnya menggunakan
Fiddler , itu akan meniru beban "nyata" pada sumber daya yang diuji.
Setelah pembuatan selesai, kami meluncurkan tes, di mana studio akan menunjukkan beberapa metrik utama, seperti kinerja dan bandwidth, serta membangun grafik waktu nyata.
Fig. 14. Proses menjalankan tes di cloudSetelah tes selesai, Anda juga dapat melihat laporan web yang disimpan dalam VSTS:
Fig. 15. Laporan web di portal Layanan Tim Visual StudioAnalisis Hasil
Poin yang paling penting adalah pemrosesan dan analisis hasil tes. Untuk tugas yang dimaksud, perlu untuk mengevaluasi kinerja aplikasi yang berjalan pada berbagai konfigurasi tarif Azure Web Apps B2 dan B3.
Untuk melakukan ini, kami menjalankan tes "direkam" lagi untuk aplikasi pada konfigurasi yang berbeda dan mencatat hasilnya dalam dokumen Excel.
Hasilnya, kami mendapat laporan ini:
Fig.16. Laporan Hasil UjiSetelah menganalisis data yang diperoleh, dimungkinkan untuk mengetahui beban maksimum yang dapat ditahan oleh aplikasi kita - sekitar 60 pengguna simultan atau 9 permintaan / detik. dengan waktu pengembalian halaman rata-rata 2,5 detik. Grafik menunjukkan bahwa masalah kinerja mulai secara tiba-tiba setelah nilai ambang tertentu untuk jumlah permintaan.
Ternyata kemudian, alasan untuk ini adalah beban prosesor 100%, karena fakta bahwa kami menggunakan perpustakaan pihak ketiga untuk rendering halaman server, yang menggunakan ekspresi reguler untuk tokenize dan parse markup.
Kesimpulan
Kinerja aplikasi yang aktif berkembang selalu memiliki kecenderungan degradasi yang sangat kuat, karena perubahan apa pun, bahkan yang paling tidak penting dari sudut pandang pengembang, dapat menyebabkan konsekuensi dramatis bagi kinerja aplikasi. Dalam hal ini, pengujian kinerja berkala adalah prosedur penting yang harus dilakukan secara teratur dan menjadi bagian dari proses Integrasi Berkelanjutan.
Proyek itu sendiri dan laporan yang diterima sebagai hasil pengujian tersedia di GitHub .