Я использую memcacheдля хранения сеансов и на страницах категорий, которые я заметил в новых транзакциях реликвии, где начало сеанса varien может занять более 30 секунд.
Это может быть связано с блокировкой сессии, но я подумал, что это не проблема при использовании memcache.
Кто-нибудь когда-либо сталкивался с этим или есть идеи, что может быть причиной этого.
Ответы:
Я видел это довольно много и на Новой Реликте.
Из того, что я видел, есть несколько разных причин, у меня нет полного понимания этой проблемы, но это то, что я недавно изучал. Вот мои выводы.
Каждое действие контроллера в Magento использует сеанс независимо от того, нужен он или нет. Сеанс с нетерпением создается в Mage_Core_Controller_Varien_Action :: preDispatch
Если у вас включена блокировка сеанса, это означает, что на время запроса ваш сеанс блокируется до тех пор, пока запрос не будет завершен. Я еще не нашел фрагмент кода, который снимает блокировку сеанса, но я почти уверен, что он где-то там есть.
В конечном итоге это означает, что если вы выполняете несколько одновременных запросов к действиям контроллера Magento из одного местоположения, используя один и тот же сеанс, вам придется ждать завершения некоторых из этих запросов и разблокировать сеанс для продолжения. Обычно я вижу это как медленную транзакцию на новой реликвии, которая застряла в Mage_Core_Model_Session_Abstract_Varien::startтечение ~ 30 секунд (я думаю, мой тайм-аут ожидания блокировки сеанса).
Этот отчет о Новой Реликвии имеет несколько минусов, как мне кажется
Я видел несколько общих причин для этого, а не окончательный список каким-либо образом
Такие сканеры, как Baidu и Yandex, немного грубоваты и портят сайт. Они запускаются из одного места, запускают многочисленные запросы, используют один и тот же сеанс и запускают механизм блокировки сеанса, следовательно, в New Relic отображаются медленные транзакции.
В случае лакированных веб-сайтов конкретные данные о клиентах должны загружаться с осторожностью, некоторые веб-сайты управляют этим с помощью вызовов ajax в бэкэнд Magento для получения необходимых данных. Я также видел некоторые веб-сайты, использующие ajax-вызовы для бэкэнда, чтобы получить информацию о продукте, такую как сумма, оставшаяся на складе, когда товар продается.
Если при загрузке страницы одна страница инициирует несколько вызовов Ajax к бэкэнду, это может потенциально вызвать механизм блокировки сеанса. Чем больше Ajax перезванивает бэкэнду Magento, тем выше вероятность того, что вы столкнетесь с блокировкой.
На самом деле то же самое, что и выше, за исключением того, что вместо использования вызовов ajax он использует Edge Side Includes, которые кажутся новыми вызовами бэкэнда.
Я еще не предпринял никаких действий, так что это все еще чисто теоретически, но я собираюсь сделать это в течение следующих нескольких месяцев.
Я поднял эту проблему во время конференции Mage Titans UK 2016, и Фабрицио Бранка указал мне на следующий модуль: https://github.com/AOEpeople/Aoe_BlackHoleSession .
Основанный на регулярном выражении, модуль не позволит ботам создавать реальные сеансы, это должно иметь преимущество, заключающееся в том, что блокировка сеанса не будет задействована, и что ресурсы вашего сеанса не пострадают от грубых ботов. Боты больше не должны загрязнять ваши показания Новой Реликвии.
Что касается вызовов ajax / ESI для получения данных о клиентах на кэшированных страницах, вы ничего не можете сделать, что я вижу. Вам нужен доступ к сеансу, чтобы получить данные о клиенте.
Однако для вызовов ajax / ESI для получения данных, специфичных для каталога (таких как ограниченный запас), я не вижу необходимости в существовании сеанса по этому запросу вообще. Мой план на будущее состоит в том, Aoe_BlackHoleSessionчтобы опробовать расширение модуля, чтобы я мог отбрасывать запросы к определенному URL-адресу как безсессионные.
Я менее знаком с внутренностями ESI, поэтому, к сожалению, у меня не так много комментариев.
Во время конференции Фабрицио Бранка сказал, что он может полностью отключить блокировку сеанса без каких-либо побочных эффектов, тестировать на свой страх и риск.