Я використовую memcacheдля зберігання сеансів і на сторінках категорій, які я помітив у нових реліктових транзакціях, де початок сеансу варіантів може зайняти понад 30 секунд.
Можливо, це може бути пов'язане із блокуванням сеансу, але я подумав, що це насправді не проблема при використанні пам’яті.
Хтось коли-небудь стикався з цим або має ідеї, що це може спричинити.
Відповіді:
Я бачив це досить багато і в Новій Реліквії.
З того, що я бачив, є кілька різних причин, я не повністю розумію це питання, але це те, що я розглядав недавно. Ось мої висновки.
Кожна дія контролера в 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 .
На основі регулярного виразу модуль не дозволить ботам створювати реальні сеанси, це повинно мати перевагу, що не заблокується блокування сеансу, і що ваші сеансові ресурси не будуть побиті грубими ботами. Боти більше не повинні забруднювати ваші читання New Relic.
Для дзвінків ajax / ESI, щоб отримати дані клієнтів там на кешованих сторінках, ви нічого не можете зробити, що я не бачу. Вам потрібен доступ до сеансу, щоб отримати конкретні дані клієнта.
Однак для викликів ajax / ESI для отримання конкретних даних по каталогу (таких як обмежений запас) я взагалі не бачу необхідності в сеансі існування цього запиту. Мій план на майбутнє полягає у випробуванні розширення на Aoe_BlackHoleSessionмодуль, щоб я міг відмовитись від запитів на певну URL-адресу як без сеансу.
Я менш знайомий з внутрішніми стандартами ESI, тому, на жаль, мені там не надто багато коментарів.
Під час конференції Фабріціо Бранка заявив, що йому вдалося повністю відключити блокування сеансу без жодних негативних наслідків, протестуйте на свій страх і ризик.