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.

我的经验是一样的.

如果你使用 aoe_static 的 awesome 模块和 phoenix 的整页缓存和 varnish 模块，你会很接近.

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

使用 aoe_static 模块缓存是基于每个 Action 完成的，这对我来说似乎很明智.打孔是使用通过布局 xml 应用的占位符和通过不会被缓存的 ajax 调用请求的动态块完成的.cookie 也是通过这个调用设置的.他提供了一个默认的 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.

缓存失效由 phoenix 模块处理得很好.您可以在模块的控制文件夹中看到方法.这会在产品或类别更改时处理缓存失效并使产品页面和类别页面失效.然而，由分层导航生成的 url 可能会被缓存(取决于您的 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.

但是对于分层导航 url，需要一个模型来记录生成的带有类别 id 的 url.我想拥有一个 2 列模型 - url 和类别 - 然后缓存失效需要检查模型并使额外的 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/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.

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

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 事件进行检查，我们应该使产品页面 url 无效.这个保存改变了评级，但我建议在 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屋！