Sesi variasi Magento mulai sangat lambat pada halaman kategori dengan penyimpanan sesi MEMCACHE


13

Saya menggunakan memcacheuntuk penyimpanan sesi dan pada halaman kategori saya perhatikan dalam transaksi peninggalan baru di mana varien sesi awal dapat memakan waktu lebih dari 30 detik.

Mungkin ada hubungannya dengan penguncian sesi, tapi saya pikir ini bukan masalah saat menggunakan memcache.

Siapa pun pernah menghadapi ini atau punya ide apa yang menyebabkan ini.

Jawaban:


5

Saya sudah melihat ini cukup banyak di New Relic juga.

Dari apa yang saya lihat ada beberapa penyebab yang berbeda, saya tidak memiliki pemahaman yang lengkap tentang masalah ini tetapi itu adalah sesuatu yang saya cari baru-baru ini. Inilah temuan saya.

Sesi di Magento, Mengunci, dan Relik Baru

Setiap aksi pengontrol di Magento menggunakan sesi, apakah perlu atau tidak. Sesi ini bersemangat dipakai di Mage_Core_Controller_Varien_Action :: preDispatch

Jika Anda memiliki penguncian sesi diaktifkan, ini berarti bahwa selama permintaan sesi Anda dikunci hingga permintaan selesai. Saya belum menemukan sedikit kode yang melepaskan kunci sesi, tapi saya cukup yakin itu ada di suatu tempat.

Pada akhirnya ini berarti jika Anda menjalankan beberapa permintaan bersamaan ke tindakan pengontrol Magento dari satu lokasi menggunakan sesi yang sama, Anda harus menunggu beberapa dari permintaan tersebut untuk menyelesaikan dan membuka kunci sesi untuk melanjutkan. Saya biasanya melihat ini sebagai transaksi lambat pada peninggalan baru terjebak pada Mage_Core_Model_Session_Abstract_Varien::start~ 30 detik (saya pikir saya menunggu waktu tunggu kunci sesi).

Laporan tentang Relik Baru ini memiliki banyak kelemahan seperti yang saya lihat

  • Memperlambat total waktu respons rata-rata, karena permintaan ini lebih lambat dari yang seharusnya.
  • Relik Baru mencatat sampel dari transaksi paling lambat, jika saya memiliki hambatan kinerja yang mengambil contoh 20 detik Relik Baru tidak akan melaporkannya secara otomatis untuk saya jika URL yang sama terganggu oleh timeout penguncian sesi. Timeout menyembunyikan data yang berguna.

Penyebab

Saya telah melihat beberapa penyebab umum untuk ini, bukan daftar definitif dengan cara apa pun

Bot

Perayap seperti Baidu dan Yandex menjadi makhluk yang agak kasar dan menghancurkan situs web. Mereka dijalankan dari satu lokasi melepaskan banyak permintaan, menggunakan sesi yang sama, dan menyandung mekanisme penguncian sesi, karenanya menunjukkan transaksi lambat di New Relic.

Ajax panggilan ke tindakan kontroler Magento

Dengan situs web yang dipernis, data khusus pelanggan harus dimuat dengan hati-hati, beberapa situs web mengelola ini dengan menggunakan panggilan ajax ke backend Magento untuk mendapatkan data yang diperlukan. Saya juga melihat beberapa situs web menggunakan panggilan ajax ke backend untuk mendapatkan informasi spesifik produk, seperti jumlah yang tersisa dalam persediaan ketika suatu barang dijual.

Jika satu halaman memicu beberapa panggilan ajax ke backend saat memuat halaman, berpotensi memicu mekanisme penguncian sesi. Semakin banyak panggilan ajax kembali ke backend Magento, semakin besar kemungkinan Anda mengalami penguncian.

Varnish ESI

Sama seperti di atas benar-benar, kecuali alih-alih menggunakan panggilan ajax menggunakan Edge Side Termasuk yang tampaknya menjadi panggilan baru ke backend.

Rencana saya

Saya belum menindaklanjutinya, jadi ini masih murni teoretis, tapi ini sesuatu yang saya coba lakukan selama beberapa bulan ke depan.

Saya mengangkat masalah ini selama konferensi Mage Titans UK 2016 dan Fabrizio Branca mengarahkan saya ke modul berikut: https://github.com/AOEpeople/Aoe_BlackHoleSession .

Berdasarkan pada ekspresi reguler, modul akan mencegah Bot membuat sesi nyata, ini seharusnya memiliki manfaat bahwa tidak ada kunci sesi akan dipukul, dan bahwa sumber daya sesi Anda tidak akan dihancurkan oleh bot kasar. Bot tidak lagi mencemari bacaan Relik Baru Anda.

Untuk panggilan ajax / ESI untuk mendapatkan data pelanggan di sana pada halaman cache tidak ada yang bisa Anda lakukan yang bisa saya lihat. Anda perlu akses ke sesi untuk mengambil data khusus pelanggan.

Namun , untuk panggilan ajax / ESI untuk mendapatkan katalog data spesifik (seperti stok terbatas) saya tidak melihat ada kebutuhan untuk sesi ada pada permintaan itu sama sekali. Rencana saya untuk masa depan adalah untuk mencoba ekstensi ke Aoe_BlackHoleSessionmodul sehingga saya dapat menutup permintaan ke URL tertentu sebagai tanpa sesi.

Saya kurang terbiasa dengan internal ESI, jadi sayangnya saya tidak punya terlalu banyak komentar di sana.

Sebuah alternatif

Selama konferensi, Fabrizio Branca mengatakan bahwa ia dapat menonaktifkan sesi penguncian sepenuhnya tanpa efek buruk, uji dengan risiko Anda sendiri.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.