Analisis Kinerja Berbasis Sampling Stacktrace

Analisis Kinerja Berbasis Sampling Stacktrace

Tutorial APM
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Di salah satu perusaahan  namun mereka  masih menggunakan perangkat lunak Jira yang masih versi lama dan peralatan IDC juga peralatanya sudah sangat tua dan pasti sulit untuk meningkatkan atau memindahkan ke peralatan baru karena kebijakan lisensi yang mengharuskan alokasi linsensi pada basis perangkat keras. sebagai pengembang mereka sangat was-was dan cemas karena waktu respon yang sangat turun dan makin memburuk, kemudian pengembangpun mencoba menginstal APM untuk melakukan profile metode,

Setelah melihat dan menggunakan grafik X-View yang merupakan fungsi utama dari APM Jennifer yang di instal pengembang dapat memeriksa transaksi.

 

Analisis Kinerja Berbasis Sampling  Stacktrace

 

Transaksi ditandai di bagian atas sumbu Y di grafik X-View

Coba drag dan tarik pada grafik X-View dan kemudian akan keluar pop up dan bisa dilihat hasilnya 

Analisis Kinerja Berbasis Sampling  Stacktrace

Ada beberapa area Tidak Diprofilkan yang bertahan lebih dari 12 detik

 

“Dibutuhkan lebih dari 12 detik untuk menyelesaikan transaksi… Apa alasannya?”

Area penundaan bukanlah suatu  hambatan seperti panggilan pada SQL atau HTTP, sehingga pengembang  merasa lelah. Mengetahui bahwa Aplikasi Jira yang dikembangkan oleh perusahaan bernama Atlassian, maka pengembang  memutuskan untuk mengonfigurasi profil paket com.atlassian. menjadi profil paket com.atlassian.

Analisis Kinerja Berbasis Sampling  Stacktrace

Tetapi setelah dikonfigurasi, tingkat penggunaan CPU sistem melebihi 52%. Setelah menenangkan diri dan penuh khawatir, pengembang  menyeret grafik X-View. Bisakah pengembang mengetahui mengapa itu terjadi?

 Baca Juga cara menggunakan profil metode dinamisAnalisis Kinerja Berbasis Sampling  Stacktrace

Meskipun banyak metode diprofilkan, sebagian besar metode membutuhkan waktu 0ms hingga 1ms. Melihat grafik X-View, waktu respons layanan sangat melambat.

Analisis Kinerja Berbasis Sampling  Stacktrace

Dalam hal ini, apakah ini upaya yang buruk untuk melakukan pembuatan profil?
Jika metode Class tertentu dalam paket yang dikonfigurasi menyebabkan penundaan, itu mungkin untuk mengetahui penyebabnya namun, dalam aplikasi modern, kinerja yang sangat buruk untuk metode tertentu yang dikembangkan oleh pengguna tidak terlalu memengaruhi waktu respons Karena di sebagian besar lingkungan, ini dikembangkan dengan menggunakan kerangka kerja yang disiapkan dengan baik. Dengan membuat profil paket com.atlassian, tidak mungkin untuk memeriksa informasi profil yang signifikan. Dalam kebanyakan kasus, cache disiapkan secara internal, dan kemungkinan besar tidak menyebabkan masalah kinerja.

Jika ada panggilan SQL atau HTTP yang membutuhkan waktu lama, maka Anda mungkin ingin menyetel target di situs jarak jauh, tetapi jika tidak, maka akan jauh lebih sulit untuk diselesaikan.
Bagaimana jika Anda mengkonfigurasi semua paket yang sesuai dengan kelas yang dimuat (!!) Mungkin kita bisa menemukannya.
Namun, karena jumlah beban tambahan dan data yang diterapkan ke aplikasi, kami harus membayar biaya yang sangat tinggi.

Baiklah, lalu bagaimana kita harus menganalisis situasinya?

Ada dua cara analisis kinerja – pembuatan profil dan pengambilan sampel.

Stacktrace penting untuk  membantu team IT dan pengembang untuk menemukan bug dalam program, biasanya untuk menemukan bug/error bisa sangat sulit. Perusahaan perangkat lunak menggunakan berbagai jenis pengujian proaktif untuk mengisolasi bagian dari lingkungan perangkat lunak untuk menemukan bug atau kesalahan dalam aplikasi. stacktrace adalah salah satu dari banyak alat yang dapat berguna dalam pengujian komprehensif.

Dalam aplikasi modern, kinerja yang sangat buruk untuk sebuah method yang dikembangkan oleh pengguna dalam sebagian besar, tidak mempengaruhi waktu respons, biasanya  dikembangkan dengan menggunakan kerangka kerja yang disiapkan dengan baik. dengan membuat profile com, oleh karena itu tidak bisa untuk memeriksa informasi profil yang sindifikan. Dalam kebanyakan kasus, cashe disiapkan secara internal, dan kemungkinan besar tidak menyebabkan masalah kinerja. Jika ada panggilan SQL atau HTTP yang membutuhkan waktu lama, maka harus menyetel target di situs, dan jika tidak, maka akan jauh lebih sulit untuk diselesaikan. Bagaimana jika anda mengkonfigurasi semua paket yang sesuai dengan kelas yang dimuat.


Ada dua cara analisis kinerja pembuatan profile dan pengambilan sampel.

1. Pembuatan Profile
Pembuatan profile ini memerlukan pengumpulan data kinerja dari setiap method yang berjalan karena untuk menemukan dan meningkatkan metode yang memakan butuh waktu lama.

 Analisis Kinerja Berbasis Sampling  Stacktrace

Melayacak dari awal sampai akhir method dan mengukur waktu respons. Method paling lambat untuk transactions 1 dan transactions 2 adalah method2 dan method4, dipisahkan kemasing masing method

2 Pengamblian sample
Ini  pengumpulan data kinerja dari setiap method yang berjalan dan menemukan maupun meningkatkan method yang mamakan waktu lama.

Analisis Kinerja Berbasis Sampling  Stacktrace

Mengumpulkan snapshot method yang berjalan di setiap thread secara berkala dan mengukur waktu respons. Pada gambar diatas, kita dapat menyimpulkan bahwa method1 adalah penyebab waktu respons yang sangat lambat. 

Jika kalian adalah seorang pengguna maka kalian harus mengetahui metode target yang akan dipantau. Jika digunakan untuk aplikasi di lingkungan yang beroperasi di aplikasi  yang sangat sibuk, kinerjanya pun sangat terpengaruh. Untuk itu kita harus mengkonfigurasi paket dengan  banyak class.

 

Salah satu method disebut sampling. method ini melibatkan pencarian lokasi botleneck berdasarkan frekuensi dengan mengumpulkan stacktrace secara berkala dari setiap utas tempat pemanggilan method yang dihasilkan, tanpa langsung melacak metode individual. (Ketika stacktrace dikumpulkan 3 kali untuk jangkauan waktu 100md, jika metode A muncul  3 kali, maka dapat diketahui metode A berjalan selama 300md ). Dibandingkan dengan method berbasis profiling, method ini kurang akurat, dan relatif kurang mempengaruhi kinerja saat mengumpulkan data.

Cari tau apa aja penyebab utama dari respon yang lambat?

  • Method yang menghabiskan banyak sumber daya CPU
  • Method yang secara sinkron memproses I/O
  • Method yang mengulangi objek koleksi besar
  • Method dengan singkronisasi utas yang tidak perlu

Dengan menggunakan method pengambilan sampling  berbasis stacktrace, memungkinkan untuk menemukan method yang disebutkan di atas tanpa memerlukan konfigurasi khusus. Karena dengan seperti itu dapat menghabiskan banyak sumber daya CPU atau memproses banyak I/O, method yang berjalan dalam waktu lama selalu berulang kali muncul di stacktrace. Tentu saja, pengambilan sampel juga bukan method baru, ada banyak tools berguna yang tersedia. Bisa juga menggunakan alat VisualVM. Secara berkala dapat mengumpulkan jejak tumpukan dari setiap transaksi dan menampilkan hasil frekuensi panggilan dengan baik, sehingga membantu anda menemukan lokasi yang lambat dengan mudah.

Analisis Kinerja Berbasis Sampling  Stacktrace

Karena memiliki resiko yang relatif lebih kecil pada kinerja, anda dapat menggunakannya di linkungan aplikasi yang memiliki lalu lintas tinggi tanpa khwatir. Itu berguna berkali-kali ketika mencoba meningkatkan kinerja server. Memeriksa jejak tumpukan individu yang dikumpulkan dari transaksi APM Jennifer. Batasan profiling yang telah dibahas sebelumnya. Ini dapat dengan mudah membuat profil method yang diinginkan secara real time, tetapi pengguna diharuskan untuk mengetahui dimana mereka bisa melihat / menemukan, tentu saja ada banyak cara untuk mengatasi masalah ini. Terutama, Setelah mengumpulkan informasi stacktrace secara real time, dapat mencari target profil.

Bagaimana mencari, mengidetifikasi dan memilih target profil dari stacktrace di port tertentu? bisa dengan menggunakan fungsi pemantauan soket, mengindentifikasi dan memilih target pembuatan profil dari stacktrace tertentu dengan menggunakan fungsi pemantauan.

Mengindentifikasi dan memilih target pembuatan profil setelah mengumpulkan stacktrace hingga ke titik dimana kelas atau method tertentu dipanggil, dengan menggunakan fungsi dynamic stacktrace. jika ada area panggilan yang tidak ditemukan menggunakan method, dan jendela pop-up X-View akan menunjukannya sebagai area tidak diprofilkan.

Analisis Kinerja Berbasis Sampling  Stacktrace

Jika ada area yang tidak diprofilkan maka membutuhkan waktu yang lama, jika anda ingin dapat memeriksa apa yang terjadi, dari perspektif pemantauan. Maka memutuskan untuk mengumpulkan stacktrace untuk setiap transaksi dan menampilkanya dalam urutan waktu yang terbaik.

Analisis Kinerja Berbasis Sampling  Stacktrace

Melihat susunan yang terlihat dalam urutan waktu, kita dapat memeriksa apa yang terjadi pada setiap transaksi. Pada tampilan gambar di atas, sebagian besar transaksi tampaknya konsisten memanggil metode Thread.sleep(). Kita bisa menebak bahwa pengembang sengaja memasukkannya untuk mengimplementasikan lingkungan demo. Dengan membuat profil method kelas yang dipatuhi di jsp, Anda dapat memeriksa apakah metode jspService membutuhkan waktu lama, tetapi anda tidak akan dapat mengetahui penyebab sampai anda memeriksa kode yang sebenarnya.

sumber