magento开源全页缓存 [英] magento open source full page cache

问题描述

我最近在与一位开发人员交谈，他说即使使用默认安装，也没有magento CE全页缓存能够完美运行.

I was speaking to a developer recently who said that no magento CE full page cache worked perfectly even with a default install.

我对此的经验是相同的.

my experience of this is the same.

如果您使用aoe_static的超赞模块和phoenix的全页缓存以及清漆模块，您将近距离接触.

if you use aoe_static's awesome module and phoenix's full page cache with varnish module you will get close.

缓存是在每个Action的基础上完成的，这对我来说似乎是明智的.穿孔是通过布局xml施加的占位符和通过ajax调用请求的动态块(不会被缓存)完成的. Cookie也会与此调用一起设置.他提供了默认的vcl，该vcl可与清漆2配合使用(我从未检查过)，并且可以很容易地更改为清漆3.

with the aoe_static module caching is done on a per Action basis which seems sensible to me. hole punching is done with placeholders applied via layout xml and dynamic blocks requested via a ajax call which won't be cached. cookies are set with this call as well. he provides a default vcl which is works with varnish 2 (i never checked) and can be easily changed for varnish 3.

cache失效.您可以在模块的控制文件夹中查看方法.当产品或类别更改时，这可以解决缓存失效的问题，并使产品页面和类别页面均无效.但是，分层导航生成的网址可能会被缓存(取决于您的vcl).这些不是无效的，所以要当心人们.

cache invalidation is handled quite well by the phoenix module. you can see the methods in the control folder in the module. this takes care of cache invalidation when products or categories are changed and invalidates both product pages and category pages. however the url's generated by the layered nav are likely to be cached (depending on your vcl). these are not invalidated, so watch out folks.

在生产现场使用这些模块之前，我真的很想知道这些模块是否存在其他问题.如果有人可以指出我的问题，我将很乐意尝试并发布解决方案.

i'd really like to know if any other problems exist with these modules before i use them on production sites. if anyone could point me to a problem i'd be happy to try and post a solution.

，但对于分层导航网址，则需要一个模型来记录生成的具有类别ID的网址.我想拥有2列模型(URL和类别)会很简单，然后缓存无效将需要检查模型并使多余的URL无效.这应该在完成主要类别网址的同时完成.听起来还不错.如果有人得到我的简短解释，请在我浪费时间之前告知我是否缺少某些东西.

but for the layered nav url's a model would be required to log the generated url's with category id. i suppose it would be simple to have a 2 column model - url and category - and then cache invalidation would need to check the model and invalidate the extra url. this should be done at the same time as the main category url gets done. doesn't sound too bad. if anyone gets my very brief explanation please advise on if i'm missing something before i waste my time.

我宁愿创建一个开源项目，该社区项目(或一些经验更丰富的人)都会提供社区帮助(至少在默认1.7版安装中具有(当之无愧的)可靠性声誉).我认为最明智的做法是创建一个包含或记录所有边缘情况(对于默认1.7安装)的模块.

i would rather create an open source project with some community help (or someone more experienced at the lead) that has a (deserved) reputation for reliability in a default 1.7 install at least. i think the most sensible thing would be to create one module with all the edge cases (for a default 1.7 install) covered or documented.

有人知道如何进行这样的任务吗?如果有更多的社区支持使用apc或memcached来做到这一点，那么对于更广泛的托管可用性而言可能更为明智.逻辑或开发时间不会有太大变化.

does anyone know how to go about such a mission? if there was more community support to do this with apc or memcached that might be more sensible for wider hosting availability. the logic or the development time wouldn't change much.

这可能会扩展到涵盖应该注意的块的会话缓存，但是我认为应该将重点放在可靠的全页缓存上.

this could be expanded to cover session caching of blocks which should be kept in mind but i think focus on a reliable full page cache should be the priority.

您还可以检测vcl中的设备.可以将其添加到想要移动版本 https://github.com/的商店中清漆/varnish-devicedetect/blob/master/devicedetect.vcl

you can also detect devices in a vcl. this could be added to shops wanting mobile version https://github.com/varnish/varnish-devicedetect/blob/master/devicedetect.vcl

我已经为此项目创建了一封电子邮件，因此，如果您想参与其中，那就是"magefpc gmail com".任何有magento，git和调试经验的人都将受到欢迎.

i've created an email for this project so if you want to be involved it's "magefpc gmail com". anyone with experience of magento, git and debugging would be welcome.

谢谢

推荐答案

我希望此帖子成为社区答案，详细说明特定句柄的方法以及建议的缓存和无效逻辑(如果尚未包含在phoenix或aoe_static中)模块.基本上，缓存将由aoe_static模块中布置的模块/控制器/动作模式完成，并且大多数现有的失效都存在于Phoenix模块中.

i'd like this post to be a community answer detailing approaches to particular handles and suggested caching and invalidation logic needed if it's not already included in the phoenix or aoe_static module. basically caching will be done by module/controller/action pattern laid out in the aoe_static module and most of the existing invalidation exists in the Phoenix module.

因此，我们需要确定应通过ajax呈现哪些块，以及需要在哪些位置使附加缓存无效.就像gondo所说的那样，您需要添加更多的无效逻辑来缓存搜索.我计划从目录，cms和aw博客页面开始做起，在这里已经做了很多工作，但还需要做更多.如果我们也可以在gondo :)的帮助下添加搜索，那就太好了.

so we need to decide which blocks should be rendered via ajax and where addition cache invalidation is required. like gondo says you'll need to add a lot more invalidation logic to cache searches. i plan to start smaller with the catalog, cms and aw blog pages, much has been done here but a little more is required. if we could add search too, with the help from gondo :), that would be great.

-小部件实例可能是一个问题，静态块保存也可能是一个问题.仅通过使用core_model_abstract方法_beforeSave()调度的事件运行总缓存失效，就可以轻松解决此问题(据我的快速调查显示).

for instance - widget instances could be a problem, as could static block saves. this can (as far as my very quick investigation has shown) be easily solved only by running a total cache invalidation using the event dispatched by the core_model_abstract method _beforeSave()

  Mage::dispatchEvent('model_save_before', array('object'=>$this));

在使整个缓存无效之前，我们需要匹配模型的类型.在缓存无效的其他困难区域中，该模式也将是实时的节省者.使用instanceof方法很好，但是我们需要知道要检查的模型名称.我猜想社区参与度很高，因为代码很简单，但却缺少模型.

we'd need to match the type of model before invalidating the entire cache. this pattern will also be a real time saver in other difficult areas of cache invalidation. using the instanceof method is fine but we'll need to know model names to check for. i guess community involvement is great here because the code's so easy but so is missing a model.

小工具本质上是相同的.带有产品的产品应该加载aoe_static，因为它们经常更改.但是静态块可以视为静态(html)块.

widgets are essentially the same from frontend point of view. the one with products should be loaded with aoe_static, as they are changing quite often. but the static ones can be treated as static (html) blocks.

在保存产品时，我们不想使整个缓存无效，并且无法检查产品是否已包含在小部件中.但是aoe_static模块可用于布局渲染.窗口小部件将需要通过布局xml而不是通常包含在所见即所得的管理中.可以将这些小部件添加到呼叫控制器的句柄中，并将其放置到所需的句柄中.

we don't want to invalidate the entire cache when a product is saved and can't check if the product has been included in a widget. but the aoe_static module works with layout rendering. widgets will need to be included via layout xml and not in the admin wysiwyg as the often are. these widgets could be added to the call controller handle and place holders to what ever handle is needed.

全清漆失效，有时不是卧床不起的事情.如果整个缓存失效发生得太频繁，或者在需要时没有发生，则是一个问题.主要目标应该是捕获每个无效方案并在管理面板中触发通知，与保存产品时获得的消息类型相同:一种或多种缓存类型已失效..." 这样，管理员可以决定是否要手动或使缓存无效.并且根据这种情况，可能会内置一些自动失效逻辑.

full varnish invalidation, time to time, is not a bed thing. the whole cache invalidation is an issue if it happens too often, or if it does not happen when needed. the main goal should be to capture every invalidation scenario and trigger notice in admin panel, same type of message as you get when you save product: "One or more of the Cache Types are invalidated..." this way admin can make the decision if he/she wants to invalidate cache manually or wait. and ofc there can be some automatic invalidation logic build in based on this scenarios.

还必须创建模型来存储由分层导航创建的网址，并且这些网址应与类别视图网址一起无效.

also the model must be created to store the url's created by layered nav and these should be invalidated along with the category view url's.

并且通常要考虑分层导航和无效性，当保存属性时，我们必须使整个缓存无效(我认为).

and with layered nav and invalidation in general in mind we must invalidate the entire cache when an attribute is saved (i think).

出于搜索引擎优化的目的，我们应该能够将产品评论放到产品页面上而不使用ajax.

we should be able to put the product reviews on the product page without ajax for seo purposes.

这意味着保存评论模型时，必须使用model_save_before事件对其进行检查，并且我们应使产品页面网址无效. 此保存更改了等级，但是我建议在ajax调用中抓住此块.对于seo来说并不重要.这适用于产品视图和列表页面.

this means when a review model is saved it must be checked using the model_save_before event and we should invalidate the product page url. this save changes the rating but i suggest this block is grabbed in the ajax call. it's not important for seo. this goes for the product view and list pages.

我们还可以缓存评论模块页面并使页面无效，但这对大多数用户而言并不重要，应等待.

we could also cache and invalidate review module pages but this isn't important to the majority of users and should wait.

谁想要标签块.这些不能由ajax加载，这违背了它们的目的.同时，现在他们不值得我们付出努力.

who wants tags blocks. these can't be loaded by ajax it defeats their purpose. at the same time they're not worth our efforts now imo.

如果您缓存带有附加的会话ID的url，则会导致用户相互告知对方会话.我认为通过基于正则表达式的vcl_fetch中的管道传递可以轻松解决此问题.

if you cache url's with the session id appended it will cause users to get each others sessions i'm told. i think this is easily solved by piping in vcl_fetch based on a regex.

此答案变得混乱，应尽快重新起草.随时添加您的2美分！

this answer is getting messy and should be redrafted sometime soon. feel free to add your 2 cents!!

这篇关于magento开源全页缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！