Comments 6
А зачем разработчики это делают самостоятельно, когда придумали ESI?
В Magento это можно реализовать через Varnish, к примеру используя модуль github.com/nexcess/magento-turpentine
Пробовали использовать это расширение, но не удалось до конца подружить как хотелось, в результате родилось свое решение без использования Varnish, часть идей кстати почерпнул именно отсюда — те же flush_events с возможностью на основе шаблона динамически навешивать обработчики — замечательная штука.
В целом само расширение неплохое, но нам до конца не подошло. Изначально были какие-то проблемы с приватными блоками и ajax блоками у расширения Ajax Cart Pro — блоки умели нормально генерироваться только через esi опрокинутые в ajax, что создавало ситуацию:
— загрузилась страница,
— делается аджакс запрос по правилу ЕСИ, где он получает некий кусок кода
— в этом куске кода js ))), который уже делает свой ажакс запрос, чтобы получить реальный блок с данными
Т.е. двойные запросы ажаксовые, а таких блоков несколько на страницу было, а если их проставлять не как ажакс — просто не отрабатывали и не обновлялись.
Думаю это побороть можно было в целом, но у нас товары обновляются часто в течении дня и по много раз — тут нужен был отложенный сброс кеша по категориям, с задержками во времени, а как это нормально привинтить к варнишу я не знал…
В целом само расширение неплохое, но нам до конца не подошло. Изначально были какие-то проблемы с приватными блоками и ajax блоками у расширения Ajax Cart Pro — блоки умели нормально генерироваться только через esi опрокинутые в ajax, что создавало ситуацию:
— загрузилась страница,
— делается аджакс запрос по правилу ЕСИ, где он получает некий кусок кода
— в этом куске кода js ))), который уже делает свой ажакс запрос, чтобы получить реальный блок с данными
Т.е. двойные запросы ажаксовые, а таких блоков несколько на страницу было, а если их проставлять не как ажакс — просто не отрабатывали и не обновлялись.
Думаю это побороть можно было в целом, но у нас товары обновляются часто в течении дня и по много раз — тут нужен был отложенный сброс кеша по категориям, с задержками во времени, а как это нормально привинтить к варнишу я не знал…
Вообще для мадженты ESI не всегда лучший подход, думаю и не только для мадженты.
По сути что делает вэб сервер (как далее пишут на примере Varnish) когда находит метку ESI — делает ещё 1 дополнительный запрос к приложению. А что если у нас на странице много блоков пользовательских / динамических — надо сделать много запросов, а они используют данные кук / сессии и прочего — получается много запросов + много раз дергаем модели для пользователя + ещё какието данные, а если ещё на этих блоках при подтягивании данных срабатывают некие события и в зависимости от них пишутся данные… — не совсем оптимальное решение иногда.
В общем не знаю как в Enterprice реализован FPC — не щупал никогда, но свой модуль FPC для Magento CE делал на основе логики такой:
1. Контроллеры всегда должны отрабатывать — не зависимо от того есть страница в кеше или нету.
Вообще это наверно наиболее спорный вопрос был, если контроллеры не отрабатывают, а страница отдается из кеша вэб сервера, снимаем часть нагрузки с сервера, однако если происходит некая бэкграундовая логика — теряем ее.
Прямой пример — сбор статистики просмотров товара: если из кэша вэбсервера — данные в системе будут искажены. Вариантов решения придумать не проблема — например через js отправлять запрос или через тот же еси дополнительный запрос, но логика некоторых модулей может быть совсем не прозрачна и навешена на определенный event…
2. Блоки должны быть нескольких типов — динамические (всегда делается генерация блока, а там если он хочет — пускай себя кеширует по своей логике), приватные (пользовательские, типа корзины / списка сравнения ...) — кешируются в сесии пользователя, обновляются по определенным событиям, и статичесие- кешируются на основе тегов, чтобы можно было сбрасывать не весь кеш при изменении одного товара или страницы
3. Для удобства помимо правил кеширования блоков добавили сквозные правила по отключению кеширования по модулям / по controller/action / по маске урла.
4. Если страницы нет в кеше — генерируем и сохраняем, заменяя все не статические блоки на плейсхолдеры
5. Если есть в кеше — подгружаем, берем список плейсхоледров, по ним определяем какие блоки надо обновить — это все динамические + приватные по условиям срабатывания событий — потом все эти блоки вместе генерируем, вставляем и отдаем ответ
При этом появляется ещё небольшое преимущество — роботам и прочим можно часть блоков не генерировать вовсе (корзины / списки сравнения / блоки пользователей в зависимости от геоположения)
По сути что делает вэб сервер (как далее пишут на примере Varnish) когда находит метку ESI — делает ещё 1 дополнительный запрос к приложению. А что если у нас на странице много блоков пользовательских / динамических — надо сделать много запросов, а они используют данные кук / сессии и прочего — получается много запросов + много раз дергаем модели для пользователя + ещё какието данные, а если ещё на этих блоках при подтягивании данных срабатывают некие события и в зависимости от них пишутся данные… — не совсем оптимальное решение иногда.
В общем не знаю как в Enterprice реализован FPC — не щупал никогда, но свой модуль FPC для Magento CE делал на основе логики такой:
1. Контроллеры всегда должны отрабатывать — не зависимо от того есть страница в кеше или нету.
Вообще это наверно наиболее спорный вопрос был, если контроллеры не отрабатывают, а страница отдается из кеша вэб сервера, снимаем часть нагрузки с сервера, однако если происходит некая бэкграундовая логика — теряем ее.
Прямой пример — сбор статистики просмотров товара: если из кэша вэбсервера — данные в системе будут искажены. Вариантов решения придумать не проблема — например через js отправлять запрос или через тот же еси дополнительный запрос, но логика некоторых модулей может быть совсем не прозрачна и навешена на определенный event…
2. Блоки должны быть нескольких типов — динамические (всегда делается генерация блока, а там если он хочет — пускай себя кеширует по своей логике), приватные (пользовательские, типа корзины / списка сравнения ...) — кешируются в сесии пользователя, обновляются по определенным событиям, и статичесие- кешируются на основе тегов, чтобы можно было сбрасывать не весь кеш при изменении одного товара или страницы
3. Для удобства помимо правил кеширования блоков добавили сквозные правила по отключению кеширования по модулям / по controller/action / по маске урла.
4. Если страницы нет в кеше — генерируем и сохраняем, заменяя все не статические блоки на плейсхолдеры
5. Если есть в кеше — подгружаем, берем список плейсхоледров, по ним определяем какие блоки надо обновить — это все динамические + приватные по условиям срабатывания событий — потом все эти блоки вместе генерируем, вставляем и отдаем ответ
При этом появляется ещё небольшое преимущество — роботам и прочим можно часть блоков не генерировать вовсе (корзины / списки сравнения / блоки пользователей в зависимости от геоположения)
65ms с полностраничным кешированием — это как-то прям сильно многовато )
или сервер слабый?
или сервер слабый?
Sign up to leave a comment.
Magento Enterprise: Что такое Full Page Cache и почему он нужен