Pada artikel kali ini saya akan membahas apa yang terjadi pada permasalahan dan cara mengatasi kegagalan PHP Sesion Hang disini saya akan mencoba memeriksa kenapa itu bisa terjadi dan bagaimana menyelesaikan masalah jika terjadi seperti ini. 

kita akan mulai dengan mencoba membuat masalah sesason hang.

Bisa di coba Saat aplikasi tidak digunakan 

Tulis skirp Php berikut.

<?php
   function useful_function() {
       sleep(1);
   }
   useful_function();
?>

Kemudian gunakan ab perintah untuk mengirim 10 permintaan silmutan ke server.

ab -c 10 -n 10 http://localhost:8999/first.php

Hasilnya akan terlihat seperti berikut

...
Concurrency Level:      10
Time taken for tests:   1.003 seconds
Complete requests:      10
...

Karena saya telah mengirim  10  permintaan simultan per detik, waktu eksekusi dari perintah di atas tentu saja 1 detik. Sekarang mari tambahkan fungsi untuk menunjukkan jumlah kunjungan halaman menggunakan PHP Session.

<?php //session_test1.php
   function useful_function(){
       sleep(1);
   }
   session_start();
   if(isset($_SESSION['visit_count'])===FALSE){
       $_SESSION['visit_count'] = 1;
   }
   else{
       $_SESSION['visit_count'] += 1;
   }
   $visit_count = 'visit_count = '.$_SESSION['visit_count'];
   echo $visit_count;
   aries_add_message_profile($visit_count); //add 'visit_count' to jennifer profiles
   useful_function();
?>

Mengirim satu permintaan melalui url, hasilnya akan terlihat seperti berikut:

curl -v http://localhost:8999/session_test1.php
*   Trying 127.0.0.1...
...
< HTTP/1.1 200 OK
< Date: Wed, 05 Dec 2018 05:34:53 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Set-Cookie: PHPSESSID=lmrfduhgfm6oik62fi2c9q4ek7; expires=Wed, 05-Dec-2018 13:34:53 GMT; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
...
visit_count = 1% 

Didalam respon kita dapat melihat bahwa jumlah kunjungan adalah 1(visit_count=1) Karena PHPSESSID telah ditambahkan ke cookie respons HTTP, pengendali sesi default PHP menggunakan cookie, dan nilai cookie PHPSESSID digunakan sebagai pengenal Sesi.

Mari kita kirim permintaan lain dengan curl, kali ini kita akan menambahkan PHPSESSID di cookie.

curl --cookie "PHPSESSID=lmrfduhgfm6oik62fi2c9q4ek7" http://localhost:8999/session_test1.php
...
visit_count = 2% 

Kali ini kita dapat melihat bahwa  visit_count=2 . Jadi fitur kunjungan halaman yang baru ditambahkn berfungsi dengan baik. kita lihat apa yang terjadi di server web. Jika mencantumkan isi direktori /tmp, Anda akan melihat bahwa file  lmrfd… . coba periksa konten file, Anda akan melihat bagaimana sesi disimpan:

visit_count|i:2;

Kasus Kegagalan Sesi PHP 1 (Mengatasi Kegagalan)

saya akan mengirim lagi mengirim 10   permintaan simultan lagi menggunakan  ab perintah, kali ini kita akan menentukan PHPSESSID sebagai cookie.

Hasil dari perintah tersebut akan terlihat seperti berikut.

ab -c 10 -n 10 -C PHPSESSID=lmrfduhgfm6oik62fi2c9q4ek7 http://localhost:8999/session_test1.php
...
Concurrency Level:      10
Time taken for tests:   10.006 seconds
Complete requests:      10
...

Anda dapat segera melihat bahwa ketika tidak menggunakan fungsi Sesi, waktu eksekusi perintah ab adalah 1 detik, namun, setelah menggunakan sesi, 10 permintaan yang sama membutuhkan waktu 10 detik.

Apm Jennifer X-View menunjukkan pola berikut.

X-View memplot waktu permintaan pada sumbu X dan waktu respons pada sumbu Y. Kita dapat melihat bahwa semua 10 permintaan datang pada saat yang sama, tetapi waktu pemrosesannya berbeda.

Jika kita memeriksa detail transaksi, kita dapat melihat bahwa waktu mulai sama untuk 10 permintaan, 16:12:52. Namun, waktu responsnya adalah 1 detik, 2 detik, 3 detik … 10 detik untuk masing-masing dari 10 permintaan. Selain itu, fungsi session_start dari permintaan yang diproses terakhir membutuhkan waktu 9 detik untuk dieksekusi. Ini karena file session handler mengunci file session.

Kasus Kegagalan Sesi PHP 2

Kali ini saya akan membuat masalahnya sedikit lebih serius. Misalkan kita memperbarui fungsi_berguna kita menambahkan koneksi database untuk fungsi itu.

<?php //session_test2.php
   function useful_function($db){
       sleep(1);
   }
   $db = mysql_connect('...');
   session_start();
   if(isset($_SESSION['visit_count'])===FALSE){
       $_SESSION['visit_count'] = 1;
   }
   else{
       $_SESSION['visit_count'] += 1;
   }
   $visit_count = 'visit_count = '.$_SESSION['visit_count'];
   echo $visit_count;
   aries_add_message_profile($visit_count);
   useful_function($db);

mysql_connect dipanggil sebelum session_start (). Dalam hal ini, jika permintaan satu Sesi dipanggil N pada saat yang sama, nomor koneksi DB juga bertambah N, untuk menghindari ini, anda tidak boleh memperoleh sumber daya sebelum session_start.

Pada saat anda mengubah kode untuk mendapatkan sumber daya DB setelah memanggil session_start (), bagan Koneksi DB Aktif terlihat seperti ini: Perhatikan bahwa jumlah koneksi DB disimpan di 1.

Pemecahan masalah dengan session_write_close

PHP .net  memperingatkan  masalah di atas dan menyarankan solusi berikut. Gunakan fungsi session_start dengan   opsi read_and_close (Opsi ini hanya tersedia untuk PHP 7.0 dan yang lebih baru.)

Setelah memodifikasi data sesi, gunakan  session_commit  atau  session_write_close  untuk melepaskan kunci sesi sesegera mungkin. Saya akan mencoba menyelesaikan masalah dengan mengambil metode kedua.

<?php
   function useful_function($db){
       sleep(1);
   }
   session_start();
   if(isset($_SESSION['visit_count'])===FALSE){
       $_SESSION['visit_count'] = 1;
   }
   else{
       $_SESSION['visit_count'] += 1;
   }
   session_write_close(); //release session lock
   $visit_count = 'visit_count = '.$_SESSION['visit_count'];
   echo $visit_count;
   $db=mysql_connect('...');
   aries_add_message_profile($visit_count);
  
  //Change _SESSION['visit_count']
   $_SESSION['visit_count'] = 'write data after session_write_close()';
   aries_add_message_profile($_SESSION['visit_count']);
   useful_function($db);
?>

 Setelah memodifikasi kode, seperti yang ditunjukkan di atas, saya akan mengirimkan 10 permintaan sekaligus.

ab -c 10 -n 10 -C PHPSESSID=lmrfduhgfm6oik62fi2c9q4ek7 http://localhost:8999/session_test3.php
...
Concurrency Level:      10
Time taken for tests:   1.007 seconds
...

Masalah teratasi. Semua permintaan diproses secara bersamaan. Namun, harus berhati-hati. Kode di atas telah mengubah $_SESSION ['visit_count'] setelah panggilan session_write_close().

Bagaimana cara kerjanya?  Mari kita lihat profil APM Jennifer.

Nilai $_SESSION['visit_count'] adalah  'tulis data setelah session_write_close()' . Anda dapat melihat bahwa itu telah dimodifikasi. Sekarang mari kita periksa isi file sess yang disimpan di direktori /tmp.

cat /tmp/sess_lmrfduhgfm6oik62fi2c9q4ek7
visit_count|i:40;

Anda dapat melihat bahwa nilai visit_count adalah  40   'tulis data setelah session_write_close ()'. Ini berarti bahwa nilai variabel $_SESSION diubah karena panggilan valid selama durasi permintaan, tetapi tidak dicatat dalam data Sesi. Ini adalah salah satu kelemahan dari  session_write_close solusi.

Jika Anda mengubah sesi. Jika anda membuat kesalahan, nilai yang anda lihat dan nilai yang disimpan dalam Sesi mungkin akan berbeda. 

Pemecahan masalah dengan Redis Session Handler

Kita akan menggunakan pengendali sesi Redis yang tidak mengunci sesi untuk menyelesaikan masalah. (Anda juga dapat menggunakan Kunci sebagai opsi.) Panggil session_test2.php (skrip yang tidak menggunakan session_write_close) yang ditentukan di atas 10 kali secara bersamaan.

ab -c 10 -n 10 -C PHPSESSID=lmrfduhgfm6oik62fi2c9q4ek7 http://localhost:8999/session_test2.php
...
Concurrency Level:      10
Time taken for tests:   1.006 seconds

Masalah telah hilang. semua permintaan diproses secara bersamaan. Juga, periksa Data Sesi.

# redis-cli
127.0.0.1:6379> KEYS *
1) "PHPREDIS_SESSION:lmrfduhgfm6oik62fi2c9q4ek7"
127.0.0.1:6379> GET "PHPREDIS_SESSION:lmrfduhgfm6oik62fi2c9q4ek7"
"visit_count|i:6;"
127.0.0.1:6379>

visit_count  dicatat sebagai 6 bukan10. Jika Anda memutuskan untuk menggunakan Redis Session Handler tanpa mengunci, Anda harus menyadari hal ini dan jangan berharap bahwa nilai yang disimpan dalam Session akan tetap utuh. Data yang membutuhkan integritas dan tidak boleh disimpan dalam Sesi.

Di atas adalah profil yang dapat diperiksa ketika  database  ditetapkan sebagai sesi di CodeIgniter. coba periksa SQL Query, pemanggilan metode session_start () membutuhkan waktu lebih dari 2 detik, yang menunjukkan bahwa kunci menyebabkan masalah. Kode CodeIgniter Controller yang digunakan untuk mereproduksi di atas ditunjukkan di bawah ini.

<?php
class Welcome extends CI_Controller {
 function __construct(){
   parent::__construct();
   $this->load->library('session');
 }
 public function index()
 {
   sleep(1);
   $this->load->view('welcome_message');
 }
}

Kodenya  session_start dan  session_write_close  tersembunyi.

Kesimpulan (Dalam Mengatasi Kegagalan)

Sejauh ini, saya mencoba membuat dan memecahkan masalah yang disebabkan oleh Session Lock. Melalui proses ini, Anda dapat memperoleh rekomendasi berikut:

• Anda perlu mengetahui kebijakan penguncian yang digunakan oleh pengendali sesi anda.
• Pengendali sesi default PHP adalah file, yang mengunci Data Sesi.
• Penanganan Sesi Redis tidak menglock. Opsi memungkinkan Anda mengubah lock.
• Handler Sesi Memcached terlock. Opsi memungkinkan Anda mengubah kebijakan lock.
• Jika pengendali sesi menggunakan lock, Anda harus membuka locknya setelah memodifikasi Sesi. (session_write_close).
• Anda harus menyadari bahwa masalah konkurensi dapat terjadi jika pengendali sesi tidak menglock, dan Anda tidak boleh menyimpan data yang memerlukan integritas dalam Sesi.

sumber

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 

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.

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 

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.

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 dinamis

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

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.

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.

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.

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.

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.

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

Setelah meningkatkan opsi pada aplikasi Jira , lihat artikel sebelumnya  tentang. Analisis Kinerja Berbasis Sampling Stacktrace [Summary View ] waktu respons  Jira telah sangat meningkat,dan bisa merasa sangat lebih baik, dapat dibandingkan dengan waktu sebelumnya. Untuk tidak mengambil resiko, saya telah mengumpulkan dan merekam informasi kinerja sebelum mengubah pengaturan. saya ingin tahu berapa banyak peningkatan yang sebenarnya. 
Saya merasakan peningkatan tetapi saya ingin memverifikasinya dengan angka. Jadi, saya membandingkan status sebelumnya dan saat ini dengan menggunakan status aplikasi, fungsi kinerja browser.

Status aplikasi
Hasil berikut adalah jumlah panggilan yang diurutkan dalam urutan menurun.

(Tampilan Sebelum perubahan)

(Tampilan Sesudah perubahan)

Sekilas, kita dapat melihat bahwa waktu respons rata-rata dan maksimum ditingkatkan.

2. Performa browser
Waktu merespon kali ini, telah membuat perbandingan beberapa faktor yang dapat mempengaruhi kinerja dengan menggunakan fungsi browser.

• Warna hijau menunjukkan status yang ada.
  
• Warna ungu menunjukkan satu bulan setelah diterapkan.
  
• Warna hijau menunjukkan status yang ada.
  
• Warna ungu menunjukkan satu bulan setelah diterapkan

Kita dapat melihat bahwa ada peningkatan keseluruhan dari situasi umum atau waktu puncak Waktu CPU per transaksi.

Garis warna biru menunjukkan waktu sebelum perbaikan sedangkan warna ungu menunjukkan waktu setelah perbaikan. Kita dapat melihat di sini juga bahwa waktu CPU pertransaksi sangat berkurang setelah perbaikan.

3. Tampilan X

(Tampilan Sebelum Perubahan)

(Tampilan Sesudah perubahan)

Terakhir, kami membandingkan data pada grafik X-View sebelum dan setelah perbaikan dilakukan. Kami dapat memeriksa bahwa ada transaksi yang lebih padat di bagian bawah  Ini berarti bahwa waktu respons secara keseluruhan ditingkatkan.

sumber

Menggunakan server API Jennifer APM Jennifer menyimpan data yang dikumpulkan per detik dalam sistem filenya sendiri. Sistem file dikembangkan untuk memproses data berukuran besar dengan kecepatan tinggi, dan perusahaan pelanggan mengumpulkan dan memproses data instans besar dengan cara yang stabil. Tetapi karena sistem file dikembangkan sendiri, ada beberapa kesulitan dalam melihat data dalam bentuk yang ingin dilihat pengguna. Jadi, banyak pelanggan memberi kami masukan bahwa mereka ingin melihat dan menggunakan data APM Jennifer dengan SQL dengan lebih bebas dan tim R&D team Jennifer telah bekerja keras untuk mempelajari cara meningkatkannya dan sebagai hasilnya menambahkan fungsi baru. Saat ini, Jennifer menyediakan dua jenis metode tampilan SQL. Pada artikel ini, saya akan menunjukkan cara melihat data dengan menggunakan server API Jennifer dan driver JDBC. Server Jennifer API beroperasi sebagai proses independen dari server APM Jennifer.  Driver JDBC mengirimkan permintaan yang diterima dari pengguna ke server API yang membaca file DB dan mengirimkan respons HTTP sebagai hasilnya.

Sebelum Anda dapat menggunakan APM Jennifer API, Anda harus memeriksa apakah file berikut ada dalam paket yang diunduh.

Setiap paket dapat diunduh dari tautan berikut.

Server API: https://github.com/jennifersoft/jennifer5-api-server

Driver JDBC: https://github.com/jennifersoft/jennifer5-jdbc-driver

File konfigurasi server Jennifer API disebut conf/api_server.conf dan disiapkan dalam format yaml.

Baca Juga Fitur dan fungsi APM

Baca Juga Pelajari Dashboard Application Status dari APM Jennifer

apiServer:
   host: "0.0.0.0"
   port: 8080               JENNIFER API server's port number
   authentication:
     id: "jennifer"          Access ID
     password: "jennifer"      Access password 

jennifer:
   dataServer:               Data server data 
     db:
       - {path: "/home/jennifer/server.data/db_data", name: "default"} dbName
   viewServer:               View server data
     db:
{path: "/home/jennifer/jennifer5-server/db_view", name: "default"}

 Jika Anda ingin melihat file DB data dari beberapa server data atau melihat server, maka tambahkan jalur direktori sebagai berikut.

db:
  - {path: "/home/jennifer/server.data/db_data", name: "default"}
  - {path: "/home/jennifer/server.data/db_data1", name: "data1"}
  - {path: "/home/jennifer/server.data/db_data2", name: "data2"}

Sekarang, mari kita pelajari cara menggunakan server API Jennifer dengan cara yang mudah.

Pertama, unzip file jennifer-api-server-{version}.zip, lalu edit jalur server tampilan atau server data di file conf/api_server.conf agar sesuai dengan jalur DB JENNIFER pengguna. Setelah Anda menjalankan file bin/api-server (atau api-server.bat), Anda dapat melihat log berikut.

Contoh) Eksekusi server JENNIFER API

Sekarang, mari kita pelajari cara menggunakan server API Jennifer dengan cara yang mudah. Pertama, unzip file jennifer-api-server-{version}.zip, lalu edit jalur server tampilan atau server data di file conf/api_server.conf agar sesuai dengan jalur DB JENNIFER pengguna. Setelah Anda menjalankan file bin/api-server (atau api-server.bat), Anda dapat melihat log berikut. Sekarang, server Jennifer API dijalankan, kita dapat melihat datanya

Karena dibuat dengan JDBC standar, kita dapat menggunakannya di hampir semua alat DB. Pada artikel ini, kita akan mempelajari cara menggunakan CLI bawaan driver, mengembangkan aplikasi tambahan, dan menggunakan DBeaver yang merupakan alat manajemen DB sumber terbuka. Pertama, ini adalah cara mengakses dengan menggunakan fungsi CLI yang disediakan oleh driver Jennifer JDBC. Seperti yang ditunjukkan berikut ini, setelah Anda menjalankan driver Jennifer JDBC, Anda dapat dengan mudah mengakses Jennifer DB.

Contoh) Menjalankan lingkungan CLI dengan menggunakan JENNIFER JDBC Driver

Menggunakan pernyataan SQL saat CLI sedang berjalan, Anda dapat melihat data Jennifer.

Contoh) Melihat daftar tabel transaksi JENNIFER di lingkungan CLI

Jika Anda ingin menerapkan fungsi tambahan dengan mengelola atau melihat Jennifer DB, Anda dapat menggunakan DriverManager untuk melihat data sebagai berikut.

//HTTP can be omitted

• DriverManager.getConnection(“jdbc:jennifer://host:port”)

// In case of port 80

• DriverManager.getConnection(“jdbc:jennifer://host”)
• DriverManager.getConnection(“jdbc:jennifer:http://host:port”)

// If dbName is distinguished

• DriverManager.getConnection(“jdbc:jennifer:http://host:port;dbName=jennifer”)

// When viewing View Server DB

• DriverManager.getConnection(“jdbc:jennifer:http://host:port;dbType=view;dbName=jennifer”)

1. Pindahkan driver Jennifer JDBC ke menu Driver Manager dan daftarkan.

2. Masukkan informasi berikut untuk akses: Class Name, Host, Port

3. Di tab properti, daftarkan dbType, dbName untuk akses. Ini cocok dengan definisi dbPath yang ditambahkan dalam pengaturan server API dan Anda dapat melewati ini jika jalur DB tunggal ditetapkan. Dalam hal ini, dbPath yang disebut "default" akan dipilih.

4. Di menu koneksi DB baru, cari driver Jennifer5 dan buat pilihan.

5. Masukkan informasi yang diperlukan untuk akses. Saat Anda memasukkan ID/Kata Sandi, gunakan yang ada di area otentikasi file konfigurasi server AIP.

6. Pilih editor SQL baru.

7. Menggunakan SQL (select * from all_tables) yang telah disiapkan sebelumnya, Anda dapat memeriksa daftar tabel yang dapat Anda lihat. Tentu saja, Anda dapat memilih nama skema untuk memeriksa informasinya.

8. Anda dapat menjalankan SQL yang Anda inginkan untuk tabel yang dikonfirmasi.

Contoh. Anda dapat menyiapkan SQL untuk tabel yang diinginkan dan menjalankannya sendiri.
Contoh tampilan data transaksi) pilih * dari transaction_1004_20210401;

Anda dapat melihat jenis tabel berikut sekarang.

•  APPLICATION_STATISTIC_domain_date
  
• TRANSACTION_doamin_date
  
• INSTANCE_METRIC_domain_date
  
• DOMAIN_METRIC_domain_date
  
• INSTANCE_domain

Bahasa SQL (apache.org)Driver Jennifer JDBC diproduksi sesuai dengan standar SQL. Untuk lebih lanjut tentang fungsi SQL dan tata bahasa untuk digunakan, lihat tautan berikut.

Sekarang, itu saja tentang cara melihat data dengan server API Jennifer dan driver JDBC. Pada artikel berikutnya, 

Sumber