Analisis hasil stress test

Setiap hari di dunia ada semakin banyak alat untuk melakukan pengujian stres. Sebenarnya, minat terhadap topik ini mulai tumbuh.

Tugas utama alat pengujian beban adalah menerapkan beban yang diberikan ke sistem. Tapi selain itu, ada satu tugas lagi yang tidak kalah pentingnya - memberikan laporan tentang hasil pengiriman beban ini. Jika tidak, kami akan melakukan pengujian, tetapi kami tidak akan dapat mengatakan apa-apa tentang hasilnya dan kami tidak akan dapat menentukan secara akurat sejak kapan degradasi sistem dimulai.



Alat pengujian paling populer saat ini adalah Gatling, MF LoadRunner, Apache JMeter. Semuanya memiliki kemampuan untuk menghasilkan laporan siap pakai pada pengujian yang dilakukan, serta grafik individual atau data mentah, yang menjadi dasar pembuatan laporan itu sendiri.







Sebelum menulis laporan apa pun, Anda perlu memahami untuk siapa kami menulisnya dan tujuan apa yang kami kejar. Tidak masuk akal untuk menambahkan banyak grafik waktu respons aplikasi ke laporan untuk setiap operasi jika tujuan Anda adalah menentukan apakah ada kebocoran memori, jika pekerjaan yang tidak stabil telah diperbaiki selama uji keandalan, atau jika Anda perlu membandingkan dua rilis satu sama lain sebagai bagian dari pengujian regresi. Untuk menjawab pertanyaan ini, Anda hanya memerlukan beberapa grafik, kecuali, tentu saja, Anda telah memperbaiki masalah dan tidak ingin memahaminya. Oleh karena itu, sebelum membuat laporan, pikirkan apakah Anda benar-benar perlu menambahkan semua grafik ke dalamnya atau hanya yang paling indikatif dan berikan jawaban untuk tujuan pengujian. Selain itu, kumpulan grafik dan analisisnya untuk laporan bergantung pada model beban yang dipilih - tertutup atau terbuka,karena model yang berbeda akan memberikan angka yang berbeda pada grafik.



Kami di Tinkoff secara aktif menggunakan alat Gatling, oleh karena itu, dengan menggunakan contohnya, kami akan memberi tahu Anda cara membuat laporan impian Anda dan ke mana mencarinya saat menganalisisnya. Saya juga ingin segera mencatat bahwa hampir semua bagan yang dijelaskan dalam artikel dapat diperoleh secara online menggunakan bundel alat Anda dengan Grafana. Ini adalah alat yang paling nyaman untuk membuat laporan dengan cepat menggunakan dasbor yang telah dikonfigurasi sebelumnya. Selain itu, ini memungkinkan Anda untuk lebih cepat membuat hampir semua grafik berdasarkan data yang Anda kirim. Sudah ada dasbor yang siap pakai untuk hampir semua alat pengujian beban. Grafik untuk alat lain - MF LoadRunner dan Apache JMeter - juga akan diberikan, analisisnya dibuat dengan analogi dengan Gatling.

Metrik dasar

Indikator

Menunjukkan distribusi kuantitatif dan persentase waktu respons permintaan menurut kelompok. Bagan jenis ini mudah digunakan untuk memberikan penilaian awal yang cepat dari hasil tes tanpa analisis yang lebih dalam terhadap bagan lainnya.



Ambang grup-ke-grup ditentukan sebelumnya berdasarkan tinjauan sejawat atau SLA (persyaratan non-fungsional). Misalnya, mungkin ada tiga kelompok:

• luar biasa - waktu respons kurang dari 50 detik;
• sedang - lebih dari 50, tetapi kurang dari 100 detik;
• mengerikan - lebih dari 100 detik.

Di Gatling, Anda sendiri dapat mengonfigurasi ambang batas untuk berpindah dari grup ke grup dan jumlahnya di file gatling.conf. Lebih baik membuat bagan jenis ini berdasarkan metodologi. APDEX (Application Performance Index)

Anda juga dapat menambahkan indikator dengan jumlah / persentase permintaan yang gagal.







Metode APDEX memungkinkan Anda menggunakan indikator dalam pengujian regresi untuk membandingkan rilis: dengan cara ini Anda dapat langsung melihat seberapa buruk atau lebih baik rilis tersebut secara umum. Sayangnya, grafik ini tidak keluar dari kotak di MF LoadRunner dan Apache JMeter, tetapi mudah untuk membuatnya menggunakan dasbor Grafana.

Tabel waktu respons

Secara default, Gatling membuat spreadsheet berdasarkan persentil, waktu respons rata-rata dan maksimum, serta kesalahan. Ini melacak melampaui SLA (kelebihan persyaratan non-fungsional). Biasanya, SLA menunjukkan persentil 95, 99 dan persentase kesalahan. Dengan demikian, tabel memungkinkan Anda untuk mendapatkan penilaian cepat dari hasil tes.



Jika Anda mengelompokkan kueri sebagai transaksi, Anda dapat melihat di tabel skor untuk kueri individu dan skor untuk seluruh grup dan transaksi sekaligus.

Bagan Pengguna Virtual

Biasanya diukur dalam potongan-potongan dan menunjukkan bagaimana pengguna memasuki aplikasi, sehingga menggambarkan profil beban yang sebenarnya. Perlu dicatat segera bahwa untuk MF LoadRunner dan Gatling grafik ini menunjukkan jumlah Pengguna Virtual, dan untuk Apache JMeter - jumlah Thread.



Grafik digunakan untuk mengontrol kebenaran aplikasi beban. Skenario desain Anda harus sesuai dengan apa yang Anda kirimkan ke sistem dalam kenyataan. Misalnya, jika Anda melihat deviasi ke atas yang besar dari skenario yang direncanakan pada diagram, itu berarti ada yang tidak beres: kesalahan dalam penghitungan, lebih banyak salinan alat muat yang diluncurkan daripada yang diperlukan, dan seterusnya. Mungkin tidak ada gunanya menganalisis grafik lebih lanjut, karena Anda mengirimkan 100 pengguna lebih banyak dari yang Anda rencanakan, dan sistem pada awalnya dirancang untuk bekerja hanya dengan 10 pengguna.

Grafik ini dibagi menjadi dua jenis:

• Pengguna Aktif menampilkan berapa banyak utas yang saat ini aktif per detik. Saat thread mulai dan berhenti, terutama dalam model beban terbuka, kecepatan ini akan berfluktuasi selama pengujian.
• Total VUsers menunjukkan jumlah utas yang telah dimulai dan dihentikan sejak awal pengujian secara total. Nyaman untuk model beban tertutup di mana ulir tidak mati.

Jenis grafik juga tergantung pada model beban:

• Model tertutup - pengguna harus masuk ke sistem sesuai dengan profil beban yang direncanakan. Jika grafik menunjukkan penurunan atau puncak, ini menunjukkan bahwa beban tidak berjalan sesuai dengan skenario yang dihitung atau direncanakan, dan memerlukan studi lebih lanjut.
• — , . , . , , / . , — .

Response Time

Paling sering diukur dalam milidetik - ini menunjukkan waktu respons untuk permintaan ke aplikasi. Waktu respons tidak boleh melebihi SLA. Grafik ini adalah alat utama untuk menemukan titik degradasi selama pengujian beban.



Jika puncak terlihat pada grafik, itu berarti bahwa pada saat itu aplikasi tidak merespons karena beberapa alasan - ini mungkin titik awal untuk penelitian lebih lanjut. Waktu respons harus seragam, tanpa puncak untuk semua operasi di seluruh langkah pemuatan, dan berkorelasi dengan proses masuknya beban. Gatling tidak menyertakan grafik waktu respons "bersih" (rata-rata, tidak teragregasi), tidak seperti alat lainnya.



Selain grafik waktu respons setiap permintaan, juga mudah untuk menampilkan garis dengan total waktu respons (Total Response Time). Dengan menghamparkan plot beban yang diterapkan (VU / RPS), Anda dapat melacak korelasi dengan peningkatan waktu respons dari peningkatan beban yang diterapkan (VU / RPS). Apache JMeter menyebut grafik ini Response Times vs Threads.



Selanjutnya, akan ada grafik, yang mana bisa banyak garis, yang masing-masing menampilkan skenario atau permintaannya sendiri. Jika Anda memiliki pengujian kompleks dengan banyak operasi dan profil non-linier, sebaiknya Anda hanya menampilkan kueri atau grup kueri yang paling representatif di laporan. Atau, Anda hanya dapat mencerminkan permintaan yang melebihi SLA / SLO, agar tidak mengacaukan jadwal dan laporan.

Variasi grafik

Modifikasi dapat dilakukan di mana persentil waktu respons diterapkan dan baris waktu respons rata-rata untuk semua permintaan ditambahkan. Penggunaan persentil di sini akan lebih tepat, karena waktu respons rata-rata sangat sensitif terhadap puncak tajam.



Dalam pengujian performa, persentil ke-95 dan ke-99 paling sering digunakan untuk kejelasan. Namun, jika Anda melihat waktu respons rata-rata, Anda harus mempertimbangkan deviasi standar (root mean square).

Distribusi Waktu Respon

Ada juga grafik yang sangat bagus yang menunjukkan ketergantungan distribusi waktu pada jumlah permintaan.



Bagan semacam ini agak mirip dengan indikator, tetapi menunjukkan gambaran yang lebih lengkap tentang distribusi waktu, tanpa pemotongan berdasarkan persentil atau agregat lainnya. Dengan menggunakan grafik, Anda dapat dengan lebih jelas menentukan batasan untuk kelompok indikator. MF LoadRunner tidak memiliki jadwal seperti itu.

Latency

Dari metrik ini, parameter tambahan Latensi (milidetik) juga dapat dibedakan - waktu latensi (paling sering ini dipahami sebagai Latensi Jaringan). Parameter ini menunjukkan waktu antara akhir pengiriman permintaan sampai paket respon pertama diterima dari sistem.

Dengan menggunakan parameter ini, Anda juga dapat mengukur latensi di tingkat jaringan jika parameter bertambah. Diinginkan bahwa itu cenderung nol. Jenis grafik ini dan berikutnya terutama digunakan untuk analisis mendalam dan menemukan masalah kinerja. Grafik ini tidak keluar dari kotak di Gatling. Di MF LoadRunner, grafik ini disebut Grafik Latensi Rata-rata di blok Grafik Virtualisasi Jaringan jika Anda telah menginstal agen pemantau.

Bandwidth

Mirip dengan metrik di atas, Anda dapat memilih parameter Bandwidth (kilobit per detik) - bandwidth saluran. Ini menunjukkan jumlah maksimum data yang dapat ditransfer per unit waktu.



Dengan mengubah parameter ini pada alat beban, Anda dapat mensimulasikan berbagai sumber koneksi ke aplikasi: jaringan seluler atau kabel 4G. Gatling versi gratis tidak memiliki grafik ini, hanya tersedia di Gatling FrontLine versi berbayar. Grafik ini di luar kotak hanya di MF LoadRunner, terletak di blok yang sama dengan Latency, dan disebut Grafik Utilisasi Bandwidth Rata-rata.

Grafik Permintaan Per Detik

Diukur dalam potongan per detik - menunjukkan jumlah permintaan yang memasuki sistem dalam 1 detik.



Grafik tersebut menunjukkan berapa banyak permintaan yang dapat ditangani sistem Anda saat dimuat, dan ini juga merupakan grafik utama untuk membuat laporan. Ini juga melacak melampaui SLA, karena dengan peningkatan beban saat melewati titik degradasi atau ekstrema lokal, kegagalan dapat diamati, dan kemudian peningkatan tajam. Paling sering hal ini disebabkan oleh fakta bahwa ketika aplikasi mulai menurun, permintaan juga mulai terakumulasi di pintu masuk ke aplikasi (antrian muncul), kemudian aplikasi memberi mereka semacam respons atau permintaan turun oleh waktu tunggu, yang menyebabkan peningkatan tajam dalam grafik - karena jawabannya sudah diterima.

1. VU, RPS/TPS , .
2. Response Time, , .

TPS

Ini diukur dalam potongan per detik dan menunjukkan jumlah transaksi (bisa ada banyak permintaan dalam satu transaksi) dalam 1 detik.



Misalnya, transaksi "memasuki akun pribadi Anda" mencakup permintaan berikut: membuka halaman utama, memasukkan login, kata sandi, menekan tombol "kirim", mengarahkan ke halaman selamat datang - per unit waktu. Di Gatling, grafik hanya dapat diperoleh dengan menggunakan Grafana, karena untuk grup dalam laporan HTML, grafik hanya dibuat berdasarkan waktu respons.

Grafik Kesalahan

Biasanya diukur dalam tingkat (potongan per detik) - grafik menunjukkan peningkatan jumlah permintaan yang salah. Ini juga mudah untuk mengukur nilai sebagai persentase dari jumlah total permintaan. Grafik ini melacak SLA di luar batas menurut jumlah atau persentase kesalahan.



Jika Anda menghamparkan grafik Waktu Respons, Anda dapat melihat bagaimana peningkatan kesalahan memengaruhi peningkatan waktu respons aplikasi.



Gatling secara default tidak memiliki grafik terpisah yang hanya menampilkan kesalahan. Di Gatling, ini digabungkan dengan grafik VU dan segera menunjukkan bagaimana peningkatan beban mempengaruhi peningkatan jumlah kesalahan, dan membantu mendeteksi ambang batas dari mana SLA terlampaui atau kesalahan muncul sama sekali. Apache JMeter juga tidak memiliki jadwal terpisah, ini digabungkan dengan grafik jumlah transaksi.

Status tanggapan HTTP

Dimungkinkan juga untuk memplot distribusi jumlah kesalahan dengan kode respons aplikasi pada grafik - lebih mudah digunakan untuk mengklasifikasikan kesalahan.



Misalnya, jika Anda mendapatkan 100% pada grafik sebelumnya, Anda mulai menganalisis kesalahan 50x mana yang disebabkan oleh server tidak merespons, atau kesalahan 403 karena kumpulan yang salah dan pengguna tidak dapat masuk, jika, misalnya, Anda menggunakan protokol HTTP.

Awalnya Gatling versi gratis tidak memiliki bagan ini, hanya tersedia di Gatling FrontLine versi berbayar. Agar grafik muncul di versi gratis, Anda perlu mengkonfigurasi ulang logback.xml sehingga log dikumpulkan di greylog, dan sudah ada di dalamnya untuk membuat grafik yang diinginkan.

Grafik throughput

Biasanya diukur dalam bit per detik. Grafik tersebut menunjukkan throughput aplikasi, yaitu seberapa banyak data yang dikirim dan diolah oleh aplikasi per satuan waktu.

Biasanya digunakan untuk analisis mendalam dari masalah aplikasi. Gatling hanya berisi grafik ini di FrontLine, bukan dalam versi gratis.

Modifikasi yang mungkin

1. Response Time, , (Throughput). Response Time, Throughput , : - .
2. Bandwidth, , .
3. VU, , , . .

Sebagian besar grafik dapat diperoleh menggunakan Laporan Gatling Berbasis HTML setelah pengujian, atau dengan mengkonfigurasi bundel pemantauan Graphite-InfluxDB-Grafana . Untuk tampilan, Anda dapat menggunakan dasbor yang sudah jadi dari perpustakaan dasbor https://grafana.com/grafana/dashboards/9935 .



Saat menganalisis dan menyusun dasbor Anda untuk Gatling, perlu diingat bahwa hasil di InfluxDB disimpan secara agregat dan hanya cocok untuk evaluasi awal hasil NT. Direkomendasikan bahwa setelah pengujian, muat ulang Simulation.log ke database dan membuat laporan akhir dan mencari masalah kinerja sistem.

Deskripsi matriks metrik

Semua yang kami jelaskan di atas disajikan dalam bentuk tablet kecil yang merangkum semua pengetahuan ini.