Magento Enterprise Какво е Full Page Cache и защо е необходим, ASTRIO

Magento Enterprise: Какво е Full Page Cache и защо е необходим.

За тези, които са запознати с Magento, не е тайна, че този двигател за електронна търговия е доста взискателен към хардуера. Но разработчиците на този онлайн магазин се опитаха да разрешат този проблем и излязоха с много различни видове „ускорители“, без които може би не си струва да стартирате магазин на Magento двигателя в производство. Magento ще отнеме твърде много време, за да предостави страницата на крайния потребител. Сред такива "ускорители" са кешове, индекси, компилация, обединяване на JS / CSS в един компресиран файл и др.

Един от основните „чипове“ на Magento Enterprise е Full Page Cache (наричан по-долу FPC). Тази функция се реализира от модула Enterprise_PageCache, който е част от пакета Magento Enterprise.

Тази статия обхваща най-новата версия на Magento Enterprise към момента на писане: 1.13.1.

FPC ви позволява да предоставите на сървъра страница за няколко милисекунди, без почти никакво натоварване на сървъра. Измерих времето, необходимо за връщане на продуктова страница от сървъра (в един от проектите, по които работих), ето резултатите:

enterprise

  • 65 ms с активиран FPC (когато всички блокове са кеширани);
  • 1250 ms с деактивиран FPC (активирани всички други видове кеш);
  • 2500 ms с деактивиран кеш от всякакъв вид.

Защо разликата е толкова голяма? Нека да го разберем.

Какво и кога кешира FPC.

В раздела frontend/cache/requests тук се посочва frontName на контролера на модула (стойността му се съхранява в конфигурацията на модула по пътя: frontend/routers/route_name/args/frontName), след това контролерът и действието (контролерът и действието са незадължителни параметри). И прехвърлената стойност е процесорът на заявката (заявката).

можете точноможете също така да принудите контролерите / контролера / действието на вашия модул да кешират, просто добавете данни към желаната секция по същия начин, както прави модулът Enterprise_PageCache. Пример:

Съществуват обаче редица условия, при които FPC не кешира страници. Не са кеширани, например HTTPS страници, страници с GET-параметър no_cache. Методите canProcessRequest и isAllowed на класа Enterprise_PageCache_Model_Processor:

Как работи FPC.

Ако страницата се кешира от FPC кеша, тогава FPC деактивира стандартния блоков кеш. Вижте метода processPreDispatch на класа Enterprise_PageCache_Model_Observer, който се задейства при възникване на събитието controller_action_predispatch:

FPC използва контейнери. Те се добавят към Magento с помощта на конфигурационния файл cache.xml в папката etc на модула. И заместителят се обработва от контейнера за контейнер. Контейнерът е класът, който ще обработва контейнера по време на FPC рендиране (процесът на рендиране на блок с FPC кеш е различен от нормалното рендиране на блок). Примерен файл cache.xml:

Накратко за конфигурацията на контейнера:

  • блок - тип или клас на блок
  • placeholder - име на контейнер
  • контейнер - тип или клас контейнер контейнер
  • cache_lifetime - живот на кеша

По време на рендиране, с активиран FPC, съдържанието на всеки блок се обвива в контейнер и се кешира: когато се задейства събитието core_block_abstract_to_html_after, се изпълнява методът renderBlockPlaceholder на класа Enterprise_PageCache_Model_Observer:

Тук $placeholder се получава с помощта на класа Enterprise_PageCache_Model_Config с помощта на метода getBlockPlaceholder:

Конструктор на класа Enterprise_PageCache_Model_Container_Placeholder:

В бъдеще вконтейнерен клас, можете да получите атрибути на блок с помощта на метода getAttribute:

Методи за опаковане на блоково съдържание с контейнер:

Пример за опаковане на съдържанието на блока с контейнер:

Преди да бъде изпратен отговорът на заявката, се задейства събитието controller_front_send_response_before и се изпълнява методът cacheResponse на класа Enterprise_PageCache_Model_Observer, който записва страницата в кеша, ако е необходимо. код на метода cacheResponse:

Тук методът processRequestResponse записва цялата страница и необходимите данни в кеша, ако е необходимо:

Тук много важен момент е, че преди да запазите страницата в кеша, съдържанието на блоковете с контейнер се заменя с описание на блоковете: $content = $processor->prepareContent($response); . метод за подготовка на съдържание:

В резултат на това кешът на страницата ще съдържа информация за блока вместо съдържанието на блока. Тази информация ще помогне за визуализирането на блока в бъдеще. Ето пример за такава информация, която FPC ще замени със съдържанието на блока по време на изобразяването му:

Следващият път, когато тази страница бъде заредена, Magento ще зареди тази страница от кеша (вижте метода extractContent на класа Enterprise_PageCache_Model_Processor). Ако кеша е празен - нормално изобразяване с Magento инициализация (все едно няма FPC) и след това запис на страницата в кеша. Ако страницата е в кеша, тогава FPC ще обработи съдържанието от този кеш.

Методите _processContent и _processContainers на класа Enterprise_PageCache_Model_Processor:

Както можете да видите от кода на тези методи, само блокове, които имат контейнери, се обработват. Ако вашият блок няма контейнер, съдържанието му няма да се промени. Следователно, ако искате да покажете динамично променящи се блокове, тогава трябва да създадетезаместители.

Контейнерите за контейнери първо се обработват от метода applyWithoutApp. Този метод се опитва да замени съдържанието на блока в кешираната страница със съдържанието, от което се нуждаем. Пример за метод applyWithoutApp, абстрактен за всички контейнери на класа Enterprise_PageCache_Model_Container_Abstract:

От кода става ясно, че ако искате да промените блока динамично, трябва да дефинирате метода _getCacheId на контейнера въз основа на логиката на вашия блок. Ако поне един контейнер не е обработен (applyWithoutApp върна false), тогава той трябва да бъде изобразен (вижте метода _processContent на класа Enterprise_PageCache_Model_Processor) и Magento ще бъде инициализирано (Mage::app() ще бъде изпълнено). В този случай заявката се обработва от контролера Enterprise_PageCache_RequestController с действието процес. Код на действие на процеса:

За всеки неизобразен контейнер се изпълнява методът applyInApp, който трябва да изобрази блока и да замени съдържанието на контейнера в съдържанието. Кодът на метода applyInApp, който е абстрактен за контейнери от класа Enterprise_PageCache_Model_Container_Abstract:

Тук, както виждаме, съдържанието се получава чрез метода _renderBlock на класа контейнер. Този метод обикновено е уникален за всеки контейнер и съдържа някаква специална логика. В абстрактния клас Enterprise_PageCache_Model_Container_Abstract за контейнери този метод връща false. Той е този, който трябва да върне HTML съдържанието на блока.

Има обаче проблем при рендиране на контейнери. За контейнерния блок родителят не може да бъде изобразен и контролерът се изпълнява по различен начин. Това означава, че може да няма данни вътре в блока и този случай трябва да се вземе предвид (например получавате продукта по този начин: $product = Mage::registry('current_product') , илизадайте някакво свойство с родителския блок: $this->getChild('block_alias')->setProduct($_product)) .

Но, както си спомняме, FPC запазва цялата информация, необходима за изобразяване. Така че, ако сте предали информация в метода getCacheKeyInfo на вашия блок за запис, можете да го зададете по време на FPC изобразяване. Трябва да направите това в метода _renderBlock на контейнера. Можете да получите екземпляр на блок в него, като използвате метода _getPlaceHolderBlock:

Както можете да видите, получаваме екземпляр на блоковия клас с набора от шаблони. Пример за метода _renderBlock:

Тук, както можете да видите от кода, предадохме манипулаторите и параметрите popup_ids на блока. В самия блок те трябва да бъдат получени така:

Кешът е наистина ефективен и работи чудесно, като намалява натоварването на сървъра и осигурява бърз магазин за електронна търговия с голям трафик.

В следващата ми статия за FPC ще опиша как да дефинирате свои собствени динамични блокове в Magento Enterprise, така че допълнителната динамична функционалност да работи правилно с активиран FPC.