caching видимость - Как включить динамический блок на странице продукта при включенном кешировании полной страницы?





выбор динамические (5)


Я очень ценю ответ Винаи. Кроме того, я бы посоветовал расширение FPC от Gordon Lesti, которое поддерживает сквозное отверстие. Вы можете получить его здесь

Для получения инструкций о том, как работа с отверстиями работает с этим расширением, я предлагаю вам посетить эту страницу

Я надеюсь, что это поможет кому-то, кто не так хорошо знаком с концепциями.

Мы хотели бы добавить динамический блок на страницу продукта. Проблема в том, что страница продукта имеет полное кэширование страниц (и мы не можем отключить это из-за проблем с производительностью). Мы хотим отображать различную информацию на каждой странице продукта на основе зарегистрированной учетной записи пользователя и варьироваться от продукта к продукту.

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

Он работает в первые несколько раз, когда я перехожу на страницы продукта, но затем неожиданно начинает отображать страницу с ошибкой Magento, в которой говорится: «На веб-сайте произошла ошибка при получении http://www.mycompany.com/productpage.html . вниз для обслуживания или настроен неправильно ».

Вот что я сделал до сих пор. Я создал приложение / код / ​​локальный / MyCompany / MyModule / PageCache / etc / config.xml для добавления MyCompany_PageCache_Model.

Затем я создал файл, который управляет кешированием в app / code / local / MyCompany / MyModule / PageCache / Model / Container / MyFile.php с этими функциями:

protected function _getCacheId()
{
    return 'CONSTANT_CACHE' . md5($this->_placeholder->getAttribute('cache_id'));
}

protected function _saveCache($data, $id, $tags = array(), $lifetime = null)
{
    return false;
}

protected function _renderBlock()
{
    $blockClass = $this->_placeholder->getAttribute('block');
    $template = $this->_placeholder->getAttribute('template');

    $block = new $blockClass;
    $block->setTemplate($template);
    $block->setLayout(Mage::app()->getLayout());
    return $block->toHtml();
}

Я также создал cache.xml под Каталогом / etc с моим заполнителем для CONSTANT_CACHE.

Является ли синтаксис выше неправильным, или есть более простой способ сделать это?




Нет необходимости:

  $info['current_product_id'] = Mage::registry('current_product')->getId();

Вы можете использовать этот метод:

$this->_getProductId()

реализовано в Enterprise_PageCache_Model_Container_Abstract




обзор

Чтобы ответить, мне нужно сначала объяснить немного. Процесс Magento FPC знает четыре состояния.

  1. Страница в кеше, никаких динамических блоков
  2. Страница в кеше, динамические блоки, кэшированные
  3. Страница в кеше, динамические блоки, не кэшированные
  4. Страница не в кеше

Состояние 1 и 2 обрабатываются без полной инициализации приложения Magento. Для состояний 3 и 4 требуется, чтобы приложение было инициализировано и маршрутизирулось для обработки. По этой причине старайтесь выполнять запросы из состояний 1 и 2, если это возможно, в противном случае вы теряете значительную часть возможных улучшений FPC.

Состояние 1

Состояние 1 скучно с точки зрения разработчика, нечего делать, поэтому давайте двигаться дальше ...

Государство 2

В состоянии 2 страница содержит динамические блоки. Сейчас Magento не был полностью инициализирован .
Процессор FPC загружает кэшированную страницу и находит в ней местозаполнитель для динамического блока.
Анализируя местозаполнитель, процессор может идентифицировать класс контейнера для динамического блока, создает его экземпляр и называет applyWithoutApp($content) . (Имя метода относится к тому факту, что приложение Magento еще не было инициализировано). Затем контейнер пытается загрузить содержимое динамического блока из кеша блока, используя ключ кэша, возвращаемый методом $this->_getCacheId() .
Если ключ кэша возвращается и запись кэша может быть загружена, класс контейнера заменяет местозаполнитель в $content выводом кэшированного блока и выполняется FPC.
До сих пор не было сделано много накладных расходов.

Государство 3

Поэтому applyWithoutApp($content) в состоянии 2 не смог извлечь и доставить содержимое динамического блока, поэтому необходимо создать контент блока, хотя остальная часть страницы была найдена в FPC.
С этой целью модуль FPC устанавливает запрос на pagecache/request/process , а также выполняется обычная инициализация и маршрутизация Magento.
Это означает, что тогда будет создано намного больше накладных расходов с состоянием 2, хотя оно по-прежнему немного лучше, чем обычная загрузка страницы без FPC, потому что, например, переписывание URL-адресов пропущено.
Наконец, фронт-контроллер и стандартный маршрутизатор делегируют запрос методу RequestController::processAction() .
Метод извлекает ранее созданный контейнерный класс для динамического блока и вызывает в нем applyInApp($content) .
Этот метод запускает $this->_renderBlock() чтобы создать экземпляр реального класса блоков и вернуть его вывод. Вы уже реализовали этот метод в соответствии с вашим вопросом. FPC теперь может заменить местозаполнитель содержимым блока и доставить страницу.
Одна вещь, о которой нужно знать, это то, что это не обычный запрос страницы детали продукта, поэтому, например, Mage::registry('current_product') недоступен! В зависимости от реализации вашего блока это может повлиять на кэширование уровня блока или создание контента динамического блока. Я подозреваю, что это может быть причиной вашей проблемы, но я немного подойду к возможному обходному пути.

Государство 4

В этом состоянии FPC не нашел запись кэша для запрашиваемой страницы, поэтому Magento генерирует страницу как обычно, например, вывод страницы детали продукта создается Mage_Catalog_ProductController::viewAction() .
Все блоки, которые настроены для динамического, в соответствии с cache.xml , завертываются в теги-заполнители.
Теги метки-заполнителя содержат аргументы, которые затем передаются объекту-контейнеру для шага 2 и 3. Единственными аргументами, которые всегда заданы, являются имена контейнеров и классов блоков. Но почти всегда устанавливается cache_id и template .
В классе контейнера эти значения можно получить с помощью $this->_placeholder->getAttribute('cache_id') (как вы это делали в методе _getCacheId () вашего контейнера).

Даже если вы замаскиваете большую часть этого длинного ответа, это то, где он может стать для вас интересным. Если вам нужны дополнительные значения для генерации идентификатора кеша блоков или вывода блока (например, идентификатор продукта или идентификатор клиента), вы можете установить их как аргументы для заполнителя .

Для этого вам нужно установить их в массиве, возвращаемом блоком getCacheKeyInfo() со строкой в ​​виде ключа массива . Если вы используете индекс числового массива, они не будут установлены в качестве аргументов в заполнителе.

public function getCacheKeyInfo() {
    $info = parent::getCacheKeyInfo();
    $info['current_product_id'] = Mage::registry('current_product')->getId();
    $info['customer_id'] = Mage::getSingleton('customer/session')->getCustomerId();
    return $info;
}

Эти значения теперь доступны в классе контейнера, используя $this->_placeholder->getAttribute('current_product_id') .

Вывод

Вероятно, вы не хотите переопределять _saveCache() в своем классе контейнера для возврата false . Вместо этого _getCacheId() идентификатор клиента и идентификатор продукта в строке, возвращаемой _getCacheId() . Таким образом, каждый клиент получает свой собственный ввод в кэш. Некоторые накладные расходы будут уменьшены, потому что applyWithoutApp() может сохранять и загружать динамический блок из кеша (если страница просматривается дважды одним и тем же клиентом).

В _renderBlock() установите дополнительные значения, необходимые для того, чтобы блок мог создавать на нем содержимое, например

$block->setProductId($this->_placeholder->getAttribute('current_product_id'));

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

Я не могу точно знать (вы не указали блок-код), но я подозреваю, что используемый вами кеш-код не содержит всех аргументов, которые ему необходимы, чтобы однозначно сопоставить запись кэш-памяти для блока с правильным продуктом ,

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




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

  1. Если ваш обратный прокси-сервер поддерживает его, вы можете использовать ESI (Edge Side Includes) и соответствующим образом пометить свой шаблон. ESI позволяет вставлять маркер в сгенерированный HTML-код, куда должен идти персонализированный контент, тогда ваш прокси-сервер будет запрашивать только персонализированный контент с соответствующего пути контроллера вашего приложения, когда это необходимо. Если вы используете Varnish , ESI доступен для использования. Расширение Lightspeed для Magento имеет функцию « Hole Punching», которая делает аналогичную вещь.
  2. Если ESI или Hole Punching недоступны для вас, тогда другая опция - разрешить кэширование главной страницы в кеше полной страницы и использовать немного javascript для создания отдельного запроса Ajax и получения необходимой информации.



Плагин mod_pagespeed Google для apache сделает автоматическое управление версиями для вас. Это действительно пятно.

Он анализирует HTML на своем пути из веб-сервера (работает с PHP, rails, python, static HTML - что угодно) и переписывает ссылки на CSS, JS, файлы изображений, поэтому они включают код id. Он обслуживает файлы с измененными URL-адресами с очень длинным контролем кеша. Когда файлы меняются, он автоматически изменяет URL-адреса, чтобы браузер мог их повторно извлекать. В основном это работает, без каких-либо изменений в вашем коде. Это даже минимизирует ваш код на выходе.





caching magento