Долгое время ответа для Mage_Core_Model_Session_Abstract_Varien

Так что я заметил в New Relic на многих наших сайтах, много наших длинных загрузок страниц происходит из-за Mage_Core_Model_Session_Abstract_Varien :: start. Я провел некоторое исследование и не видел, чтобы кто-то еще говорил об этом.

Мы используем Nginx, PHP FPM, Redis для кэширования и Memcache для сессий. Некоторые из моих идей заключаются в том, что, возможно, это что-то еще, что требует вечности, и просто кажется, что загрузка сеанса является проблемой. Или каким-то образом есть некоторый пользовательский код, добавляющий много данных в сеанс, вызывающий огромные сеансы.

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

Некоторые из этих нагрузок составляют от 20 до 30 секунд. Мне просто любопытно, заметил ли кто-то еще это или имел больше знаний о том, как анализировать эти типы длинных запросов из-за сеансов.

performance session

— dan.codes
источник

Я заметил то же поведение с Redis, используемым в качестве хранилища сеансов. Понятия не имею, почему это происходит.

Вы уже смогли найти причину этого? У меня очень похожая настройка (Redis для кеша, memcached для сессий), и недавно мы начали использовать New Relic для отслеживания производительности. Мы обнаруживаем более 20 секундных следов, которые, как вы видели, вызваны чем-то в MCMSAV :: start. К сожалению, я не могу заглянуть глубже, подсказка говорит: «Более глубокая видимость недоступна, потому что эти классы и методы не оснащены текущей конфигурацией агента PHP». Мне еще предстоит расследовать дальше. Есть идеи?

— BrianVPS

@BrianVPS Я ничего не нашел. Это остается загадкой для меня, и никогда не было больше времени, чтобы выследить это. Я все еще вижу это в каждом проекте. Вы когда-нибудь что-нибудь находили?

— dan.codes

Я не знаю, нашли ли мы какие-либо причины, но я не видел это в последнее время. Мы внесли значительные изменения в сайт и урезали много жира. Я отключил некоторые неиспользуемые основные модули, удалил массу неиспользуемых атрибутов, категорий и продуктов. С тех пор все улучшается на всех фронтах. Я не знаю, было ли это связано, но в целом избавление от ненужных вещей, похоже, значительно помогает Magento. Это мощная, но раздутая система с большим количеством кода, который не нужен многим сайтам. Избавиться от лишнего очень полезно.

— BrianVPS

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

— Денис Спаленца

Скорее всего, это связано с явлением, связанным с сеансами файловой системы. Несмотря на то, что вы сообщаете об использовании Mecached для сессий, я сам видел это только тогда, когда фактически использовал файловую систему.

Это было рассмотрено ранее здесь:

/magento//a/3721/336

На самом деле скриншот cachegrind показывает точную точку, в которой запуск сеанса занимает слишком много времени, Mage_Core_Model_Session_Abstract_Varien::startкак вы правильно указали:

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

В упомянутом потоке было высказано предположение, что этот эффект может быть уменьшен с помощью хранилища сеансов в памяти, но нет конкретных данных, о которых я знаю, чтобы поддержать теорию. Если вы на самом деле используете memcached, то понятно, что блокировка сеанса на уровне PHP будет препятствовать выполнению будущих запросов к хранилищу сеансов до снятия блокировки.

В целом это обычно наблюдается только для запросов, требующих доступа к информации о сеансе, поэтому при разработке вашей внешней темы будет полезно ограничить объем доступа, необходимый для предотвращения потенциальных блокировок, когда пользователь принимает другую вкладку или другой длительный запрос в процессе выполнения при принятии решения. отойти.

HTH, ура.

— philwinkle
источник

Долгое время ответа для Mage_Core_Model_Session_Abstract_Varien :: start