Тривалий час відгуку для Mage_Core_Model_Session_Abrief_Varien :: start


15

Тож я помітив у Новій Реліквії на багатьох наших сайтах, багато завантажень наших довгих сторінок відбувається завдяки Mage_Core_Model_Session_Ab абстракт_Varien :: start. Я провів деякі дослідження і насправді не бачив, щоб хтось говорив про це.

Ми використовуємо Nginx, PHP FPM, Redis для кешування та Memcache для сеансів. Деякі мої ідеї полягають у тому, що, можливо, це щось інше, що вічно, і просто здається, що проблема завантаження сеансу. Або якимось спеціальним кодом додається багато даних до сеансу, що спричиняє величезні сеанси.

Я не настільки обізнаний з точки зору сеансів і способів управління ними, однак я знайшов деякі статті, що розповідають про блокування сеансу. Однак я не думаю, що люди відкривали б стільки сторінок одночасно.

Деякі з цих навантажень приблизно 20 - 30 секунд. Мені просто цікаво, чи хтось ще помітив це чи мав більше знань про те, як аналізувати такі типи довгих запитів через сеанси.


1
Я помітив таку саму поведінку з Redis, який використовується як зберігання сеансів. Немає жодних підказок, чому це теж відбувається.

2
Ви вже змогли з'ясувати причину цього? У мене дуже схожа настройка (Redis for cache, memcached for session), і ми нещодавно почали використовувати New Relic для відстеження продуктивності. Ми вловлюємо приблизно 20+ секундних слідів, які, здається, спричинені чимось у MCMSAV :: почніть так, як ви бачили. На жаль, я не можу побачити це глибше, в підказці сказано: "Поглиблена видимість недоступна, оскільки ці класи та методи не оснащені поточною конфігурацією агента PHP". Мені ще належить розслідувати. Будь-які ідеї?
BrianVPS

1
@BrianVPS Я нічого не знайшов. Для мене це залишається загадкою, і ніколи не було більше часу, щоб відстежити це. Я все ще бачу це у кожному проекті. Ви коли-небудь щось знаходили?
dan.codes

1
Я не знаю, чи знайшли якісь причини, але я цього не бачив останнім часом. Ми внесли значні зміни на сайт і обрізали багато жиру. Я відключив деякі невикористані основні модулі, видалив тону невикористаних атрибутів, категорій та продуктів. З цього часу все покращується на всіх фронтах. Я не знаю, чи було це пов’язано, але загалом, позбавлення від зайвих речей, здається, допоможе Magento значно. Це потужна, але роздута система з великою кількістю коду, яка багатьом сайтам не потрібна. Позбавлення від зайвого дуже корисно.
BrianVPS

@BrianVPS У мене точно така ж проблема (20+ секундних слідів, які, здається, викликані чимось у MCMSAV :: start). Ви знайшли якесь рішення?
Денис Спаленца

Відповіді:


7

Це, швидше за все, пов'язане з явищем щодо сеансів файлової системи. Незважаючи на те, про що ви повідомляєте, використовуючи Mecached для сеансів, я це коли-небудь бачив сам, коли насправді я використовував файлову систему.

Це вже було розглянуто тут:

/magento//a/3721/336

Насправді скріншот кешгринда розкриває точний момент, у який запуск сеансу займає непомірний проміжок часу, Mage_Core_Model_Session_Abstract_Varien::startяк ви правильно вказали:

введіть тут опис зображення

У посиланні, що посилається, було висловлено припущення, що цей ефект може бути зменшений при зберіганні сеансу в пам'яті, але не існує конкретних даних, які я знаю для підтвердження теорії. Якщо ви насправді використовуєте memcached, то, очевидно, заблокування сеансу на рівні PHP не дозволить надавати майбутні запити на зберігання сеансу до моменту виходу блокування.

Як правило, це зазвичай спостерігається лише в запитах, що вимагають доступу до інформації про сеанс, тому для архітектури вашої теми інтерфейсу буде корисно обмежити кількість доступу, необхідний для уникнення можливих блокувань, коли користувач має іншу вкладку чи інший тривалий запит, коли приймається рішення відійти.

HTH, ура.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.