Setelah uji stres Performance Testing Service (PTS) selesai, PTS secara otomatis mengumpulkan data pengujian dan menghasilkan laporan. Laporan tersebut mencakup metrik tingkat skenario, detail bisnis per-Sampler, kesehatan load generator, serta log sampling tingkat permintaan—menyediakan semua yang Anda butuhkan untuk mengevaluasi kinerja sistem dan mengidentifikasi bottleneck.
Prasyarat
Sebelum memulai, pastikan Anda telah:
Menyelesaikan pengujian kinerja JMeter di PTS. Laporan JMeter ditandai dengan ikon tag JMeter
pada daftar laporan.
Buka laporan
Masuk ke Konsol PTS dan pilih Performance Test > Reports.
Temukan laporan yang dituju dan klik View Report di kolom Actions.
Log sampling disimpan selama 30 hari. Setelah periode ini berakhir, Anda tidak dapat lagi melihat log sampling tersebut. Untuk mencegah kehilangan data, ekspor laporan ke perangkat on-premises Anda sebelum periode retensi berakhir.
Bagian laporan
Laporan pengujian kinerja JMeter terdiri dari empat bagian: Business Monitoring, Load Generator Monitoring, Request Sampling Log, dan JMeter Logs.
Business monitoring
Navigasikan ke Global Monitoring > Business Monitoring untuk melihat metrik tingkat skenario dan rincian per-Sampler.
Tampilan ini berisi dua kelompok metrik:
Metrik skenario merangkum keseluruhan pelaksanaan pengujian:
| Metric | Description |
|---|---|
| VUM | Total sumber daya yang dikonsumsi, diukur dalam Virtual User Minutes (VUM). Satu VUM setara dengan satu virtual user yang berjalan selama satu menit. |
| Scenario Concurrency | Jumlah virtual user konkuren aktif. Selama fase warm-up, nilai ini meningkat hingga mencapai tingkat konkurensi yang dikonfigurasi. Setelah fase warm-up selesai, nilainya sesuai dengan konfigurasi. |
| Scenario TPS (s) | Total permintaan dalam semua periode statistik agen dibagi dengan waktu. |
| Total Requests | Total permintaan yang dikirim selama seluruh skenario. |
| Successful RT Avg (ms) | Rata-rata Response Time (RT) untuk semua permintaan yang berhasil. Nilai yang stabil atau rendah menunjukkan kinerja backend yang konsisten. |
| Failed RT Avg (ms) | Rata-rata RT untuk semua permintaan yang gagal. Bandingkan dengan RT permintaan berhasil untuk menentukan apakah kegagalan berkaitan dengan timeout atau penolakan langsung. |
| Success Rate | Persentase permintaan yang berhasil dari seluruh agen. |
| Load Source | Asal traffic pengujian: internet publik di Tiongkok daratan, atau Alibaba Cloud VPC. |
| Specified IP Addresses | Jumlah alamat IP sumber yang dikonfigurasi dalam pengaturan beban skenario. |
Metrik bisnis memecah kinerja berdasarkan masing-masing Sampler:
| Metric | Description |
|---|---|
| Sampler Name | Nama Sampler atau total agregat seluruh skenario. |
| Total Requests | Total permintaan yang dikirim oleh Sampler ini. |
| Average TPS | Nilai TPS rata-rata skenario saat ini selama periode pengujian kinerja. Dihitung sebagai total permintaan selama pengujian kinerja Sampler dibagi durasi pengujian kinerja. |
| Success Rate | Persentase permintaan yang berhasil untuk Sampler ini. Klik jumlah keberhasilan atau kegagalan untuk langsung menuju entri log terkait. Klik Details untuk melihat jumlah kegagalan yang dikelompokkan berdasarkan kode status HTTP (2XX, 3XX, 4XX, 5XX) dan exception lainnya. Di bawah other exceptions, lihat peringkat error, pesan error, serta distribusi persentasenya. |
| Average Response Time | Waktu respons rata-rata untuk Sampler ini. Klik Details untuk melihat waktu respons maksimum, minimum, dan persentil. |
| Traffic (Send/Receive) | Total byte yang dikirim dan diterima oleh Sampler ini. |
Interpretasi metrik bisnis
Gunakan pola-pola berikut untuk mengidentifikasi masalah kinerja umum:
Waktu respons datar meskipun beban meningkat: Sistem menangani beban dengan baik. Ini adalah pola yang diharapkan untuk layanan yang sehat.
Waktu respons meningkat dengan TPS stabil: Backend mendekati titik jenuh. Tingkatkan sumber daya atau optimalkan titik akhir yang lambat.
TPS stagnan meskipun konkurensi meningkat: Terdapat bottleneck—kemungkinan besar pada lapisan aplikasi, database, atau jaringan. Periksa Sampler paling lambat untuk petunjuk lebih lanjut.
Tingkat keberhasilan menurun: Permintaan gagal semakin banyak. Kelompokkan error berdasarkan kode status HTTP menggunakan Details untuk mengisolasi akar penyebab (misalnya, 429 karena rate limiting atau 503 karena overload layanan).
Load generator monitoring
Navigasikan ke Global Monitoring > Load Generator Monitoring untuk memeriksa kesehatan mesin yang menghasilkan traffic pengujian.
Tampilan pemantauan menampilkan lokasi, lebar pita jaringan, utilisasi CPU, dan Penggunaan memori setiap load generator. Pantau metrik ini untuk memastikan load generator itu sendiri tidak menjadi bottleneck yang dapat mengganggu hasil pengujian.
Request sampling log
Klik Request Sampling Log, lalu klik View Details pada permintaan apa pun untuk memeriksa informasi General dan Timing Waterfall-nya.
Log sampling berguna untuk mendebug kegagalan permintaan individual. Timing Waterfall memvisualisasikan di mana waktu dihabiskan pada setiap fase permintaan, sehingga memudahkan identifikasi tahapan yang lambat.
JMeter logs
Klik JMeter Logs untuk melihat dan mengambil output log mesin JMeter.
Gunakan log JMeter untuk memecahkan masalah tingkat skrip seperti konfigurasi thread group yang salah, error plugin, atau kegagalan assertion yang tidak muncul dalam metrik bisnis.
Data pemantauan dikumpulkan melalui Backend Listener. Baik periode sampling agen maupun periode agregasi data adalah 15 detik, sehingga metrik mungkin menunjukkan sedikit keterlambatan dibanding kondisi real-time.
Pemecahan masalah umum
| Symptom | Likely cause | Action |
|---|---|---|
| Tingkat error tinggi dengan kode 5XX | Overload atau crash pada layanan backend | Periksa log aplikasi dan tingkatkan sumber daya backend. |
| Tingkat error tinggi dengan kode 4XX | Parameter permintaan salah atau masalah otentikasi | Tinjau konfigurasi Sampler dan header permintaan di log sampling. |
| Lonjakan waktu respons di awal pengujian | Cold start, cache miss, atau inisialisasi connection pool | Jalankan pengujian warm-up singkat terlebih dahulu, atau kecualikan fase warm-up dari analisis. |
| CPU load generator tinggi | Generator kelebihan beban | Distribusikan beban ke lebih banyak generator atau kurangi konkurensi per generator. |
| Metrik menunjukkan keterlambatan tak terduga | Jendela agregasi 15 detik | Ini merupakan perilaku yang diharapkan. Tunggu setidaknya dua siklus agregasi sebelum menarik kesimpulan. |
Langkah selanjutnya
Test metrics: Referensi lengkap untuk semua metrik PTS beserta definisinya.
Technical guide for performance testing: Praktik terbaik untuk merancang dan menjalankan uji stres.
Test analysis and tuning: Panduan untuk menginterpretasikan hasil dan mengoptimalkan kinerja sistem.