Analisis Kinerja Berbasis Sampling Stacktrace III

Pada artikel sebelumnya saya membahas, tentang Analisis Kinerja Berbasis Sampling Stacktrace karena transaksi menjalankan tugas yang relatif sederhana, daftar stacktrace dapat membantu anda memahami semua yang terjadi dalam sebuah method. Namun jika kita beramsusi bahwa transaksi yang berjalan untuk beberapa waktu yang lama dan memiliki sekitar 100 stacktrace yang dikumpulkan, maka akan sangat memakan waktu untuk memeriksa setiap stacktrace.
Apm Jennifer menyediakan dua pungsi tampilan yang berbeda dan dapat menampilkan analisis yang mudah dalam situasi seperti itu.

Summary Viewing
Summary Viewing dan menganalisis, meringkas panggilan dari setiap method yang menampilkan hasil dari chart setiap transaksi, ditampilkan sebagai chart mewakili method dalam stacktrace dan memiliki informasi sebagai berikut.

 Flame chart memiliki karakteristik sebagai berikut

• Setiap warna menunjukkan  itu adalah method dari paket yang sama.
• Ukuran luas persegi panjang adalah jumlah koleksi.
• method di bagian bawah grafik adalah titik awal stacktrace.
• method di bagian atas grafik adalah method yang sedang berjalan.

Berdasarkan fakta diatas, untuk menemukan method yang paling sering dipanggil selama periode tersebut, anda harus menemukan area dengan ukuran terbesar. kemungkinan method yang anda temukan merupakan penyebab utama selama ini (penggunaan CPU, penundaan waktu respons).

Sekarang, mari kita menganalisis keadaan dengan menggunakan fungsi stacktrace yang ditingkatkan oleh APM JENNIFER. dan mari kita periksa informasi detail transaksi yang lambat di jendela pop-up X-View.

Node yang tidak diprofilkan menempati sebagian besar waktu proses. Kita dapat melihat bahwa node yang tidak diprofile memiliki sub node yang disebut STACK-TRACE. Ini adalah tampilan dari kumpulan stacktrace berdasarkan setiap profil dan informasi waktu. gambar di atas menunjukkan bahwa 95 tumpukan jejak dikumpulkan di area tidak diprofilkan. sekarang, klik node STACK-TRACE untuk pindah ke tab stacktrace di mana grup tumpukan yang cocok dipilih secara otomatis.

 

95 stacktraces dikumpulkan di bagian waktu yang dipilih. waktu yang ditampilkan di sebelah kiri berarti waktu pengumpulan antrean dari setiap warna menunjukkan jenis pencarian kumpulan. bagian berurutan dengan warna yang sama menunjukkan bahwa method yang sama berjalan secara berurutan.

Pada tab time line sebelumnya, kita bisa melihat ada 95 stacktraces di bagian time. (warna di depan waktu menunjukkan jenis stacktrace.) jika ada bagian yang terhubung dengan warna yang sama, itu berarti mereka dikumpulkan secara berurutan, dan kita dapat menebak bahwa itu telah berjalan untuk waktu yang lama. berarti, ini adalah method yang lambat.

Dalam transaksi ini, khususnya, method String.intern() dipanggil berkali-kali.

Anda dapat menggeser ke bawah untuk menemukan bagian yang terhubung dengan warna yang sama, tetapi menggunakan ringkasan, anda dapat menemukan method yang berjalan untuk waktu yang lama dengan lebih mudah.

1. Summary Viewing

Anda dapat mengklik opsi tampilan Summary untuk memeriksa hal berikut.

Grafik diatas menunjukkan hasil yang diperoleh dengan mengintegrasikan panggilan dari setiap method yang ditunjukkan dalam 95 tumpukan jejak yang dikumpulkan. Di sini, untuk menemukan method paling lambat atau method yang paling sering berjalan, anda harus menemukan simpul di mana bilah kuning menempati ukuran area terbesar. method  String.intern() menempati 37,89%. (Dengan waktu, butuh sekitar 3,6 detik.).

Method warna biru adalah yang termasuk method paling lambat tersebut. Dari sudut pandang analisis, jika anda ingin menemukan method yang paling sering dipanggil terlebih dahulu dari pada menjalankan method, maka fokuslah pada pencarian node ini.

2. Flame chart
Lihat Flame Chart sekarang?

Pada gambar diatas kita bisa lihat method paling lambat berada di bagian atas area persegi, yang menempati ukuran area terbesar. Sepintas, kita dapat mengetahui bahwa method  java.lang.String.intern() paling sering dijalankan method dalam satu spasi di bawah ini adalah metode yang disebut method java.lang.String.intern(), dengan kata lain adalah method com.atlassian.jira.web.bean.BackingI18n.flattenResourceBundlesToMap(BackingI18n.java:658). Dengan menggunakan ketiga method tersebut, maka dapat kesimpulan bahwa method yang paling lama berjalan adalah metode String.intern dan method yang disebut method ini adalah method BackingI18n.flattenResourceBundlesToMap.

Sekarang, bagaimana cara mengetahui method ini lambat?

Pertama, saya ingin memeriksa kelas BackingI18n. Melihat nama paket, itu adalah atlassian, kode untuk Aplikasi Jira. Ini berarti bahwa kita tidak dapat membuka kode sumber modifikasi kita.

Kemudian, mari kita fokus pada analisis method String.intern. Ini adalah method asli yang disediakan oleh versi JDK dasar. Jika string teks yang dikirim sebagai parameter ke kumpulan string teks yang dikelola oleh JVM tidak ada di kumpulan string teks, maka string tersebut dimasukkan sebelum dikembalikan. maka akan dikembalikan setelah menemukan kecocokan di kumpulan string teks. Sederhananya, ini mencegah pembuatan duplikat dari string teks yang sama, sehingga mengurangi tingkat penggunaan memori, dibutuhkan lebih dari 3 detik.

Buka Google dan cari  string. intern performance issue

 

Melihat hasil pencarian yang pertama kita temukan adalah informasi tentang method String.intern yang diimplementasikan dan dioperasikan secara berbeda untuk setiap versi JDK.

http://Java-performance.info/string-intern-in-Java-6-7-8/

Berikut ini adalah ringkasan dari konten di atas.

JDK6 – Kumpulan string teks dikelola di area PermGen dan ukurannya tetap, jadi anda tidak disarankan untuk menggunakannya. Tetapi Anda disarankan untuk menerapkan kumpulan string teks sebagai map.
JDK7 – Kumpulan string teks dikelola di area heap. Ukuran default 1009 hingga tepat sebelum jdku40. Meningkat menjadi 60013 di jdku40.
JDK8 – Kumpulan string teks dikelola di area heap. Ukuran default 60013

versi JDK adalah 1.7.0_25.

Dari sini kita dapat mengasumsikan bahwa ukuran default kumpulan string teks adalah 1009 dan karena string teks yang melebihi ukuran ini terakumulasi, distribusi hash yang terus gagal. (Kecuali data dalam map dikirimkan dengan menggunakan algoritma hash yang tepat, semakin banyak data maka semakin lambat kecepatannya). Jika ini adalah penyebab dari penurunan kinerja, maka anda dapat meningkatkan kinerja hanya dengan meningkatkan ukuran kumpulan string teks.

Saya mengatur ukuran kumpulan string teks dalam skrip Jira sebagai berikut. Ukurannya sama dengan ukuran default JDK8.

Sekarang coba restart Aplikasi Jira dan lihat apakah ada perubahan??

sumber