magento开源全页面缓存
我最近与一位开发者交谈，他说，即使使用默认安装，没有magento CE全页缓存也能够完美工作。
我对此的感受是一样的。
如果你使用aoe_static的真棒模块和phoenix的全页面缓存与清漆模块，你会接近。
与aoe_static模块缓存是基于每个行动的基础上，这似乎是明智的。 通过布局xml应用占位符并通过不会被缓存的ajax调用请求动态块，从而完成孔打孔。 Cookie也与此调用一起设置。 他提供了一个默认的vcl，它可以和清漆2一起使用（我从来没有选中过），并且可以很容易地更换为清漆3。
phoenix模块对缓存失效进行了很好的处理。 你可以看到模块中控制文件夹中的方法。 这会在产品或类别发生更改时处理缓存失效并使产品页面和类别页面无效。 但是由分层导航生成的url可能会被缓存（取决于你的vcl）。 这些都没有失效，所以小心别人。
我很想知道这些模块是否存在其他问题，然后在生产站点上使用它们。 如果有人能指出我的问题，我很乐意尝试并发布解决方案。
但对于分层导航网址，需要使用模型来记录生成的网址与类别ID。 我想这将是一个简单的2列模型 - 网址和类别 - 然后缓存失效将需要检查模型和无效额外的网址。 这应该在主类别url完成的同时完成。 听起来不错。 如果有人得到我非常简短的解释，请告诉我在我浪费时间之前是否错过了一些东西。
我宁愿创建一个开源项目，其中包含一些社区帮助（或者更有经验的领导者），至少在默认的1.7版安装中具有（当之无愧的）可靠性声誉。 我认为最明智的做法是创建一个包含所有边界案例（用于默认1.7版本）的模块。
有没有人知道如何去做这样的使命？ 如果有更多的社区支持可以通过apc或memcached来实现这一点，那么对于更广泛的主机可用性可能更明智。 逻辑或开发时间不会有太大变化。
这可以扩展到包含应该牢记的块的会话缓存，但我认为应该将重点放在可靠的整页缓存上。
您也可以在vcl中检测设备。 这可以添加到想要移动版本的商店https://github.com/varnish/varnish-devicedetect/blob/master/devicedetect.vcl
我为这个项目创建了一封电子邮件，所以如果你想参与，那就是“magefpc gmail com”。 任何有magento，git和调试经验的人都会受到欢迎。
谢谢
1问题你可能对aoe_static有什么问题，目前该扩展没有记录产品，所以后端关于被查看产品的统计数据不会被更新。 这是最近作为TODO注释添加到github中的。
varnish和magento缓存的问题在于，magento缓存部分页面，块和varnish确实缓存整个页面。 所以即使菲尼克斯解决方案有观察员就位，并根据产品/类别更新重新设置清漆，但您仍然有magento中的块需要重新设置。 aoe_static试图解决这个问题，但它只对页面上的可见块有效。 但是作为分层导航的magento的其他部分可能会在产品/类别更新的内部重新设置，但不会在清漆中重置。 有2个解决方案。 或者在前端识别magento的每个部分，然后在产品/类别更新后不重置什么，并对其应用aoe_static解决方案。 这意味着你将不得不通过ajax加载分层导航。 或者第二种解决方案是，将更多逻辑添加到phoenix扩展中以使更多清漆页面失效。
我有几个自定义扩展（页面什么显示产品），我建立逻辑，使每次产品/类别更新时这些扩展无效。 现在我正在研究搜索，因为这也需要失效，但复杂的部分是，解决块和缓存无效逻辑。
总而言之，正确的缓存失效是Web开发中最困难的部分之一。
我希望这篇文章是一个社区答案，详细介绍特定句柄的方法，并建议缓存和失效逻辑，如果它尚未包含在phoenix或aoe_static模块中，则需要这些逻辑。 基本上缓存将通过aoe_static模块中布置的模块/控制器/操作模式完成，并且大多数现有失效存在于Phoenix模块中。
所以我们需要决定哪些块应该通过ajax渲染，并且需要添加缓存失效。 像gondo说你需要添加更多的无效逻辑来缓存搜索。 我打算从目录，cms和aw博客页面开始缩小，这里已经做了很多工作，但需要多一点。 如果我们也可以在gondo :)的帮助下添加搜索，那就太好了。
例如 - 小部件实例可能是一个问题，静态块保存也是如此。 只要运行core_model_abstract方法_beforeSave（）调用的事件来执行总缓存失效，就可以很容易地解决这个问题（就我的非常快速的调查结果而言）
Mage::dispatchEvent('model_save_before', array('object'=>$this));
我们需要在使整个缓存无效之前匹配模型的类型。 这种模式在缓存失效的其他困难领域也将是一个真正的节省时间。 使用instanceof方法很好，但我们需要知道模型名称来检查。 我猜这里的社区参与很棒，因为代码非常简单，但是如此简单，却缺少一个模型。
从前端角度来看，小部件基本上是相同的。 带产品的人应该加载aoe_static，因为他们经常改变。 但静态的可以被视为静态（html）块。
我们不希望在保存产品时使整个缓存失效，并且无法检查产品是否已包含在窗口小部件中。 但是aoe_static模块可以处理布局渲染。 小部件需要通过布局xml包含，而不是像往常一样包含在管理员wysiwyg中。 这些小部件可以添加到呼叫控制器手柄中，并将持有者放置到需要处理的地方。
无时无时无效的清漆不是一件容易的事情。 整个缓存失效是一个问题，如果它发生得太频繁，或者如果它不在需要的时候发生。 主要目标应该是捕获每个失效方案并触发管理面板中的通知，与保存产品时获得的消息类型相同：“一种或多种缓存类型失效......”这样管理员可以做出决定如果他/她想手动使缓存无效或等待。 并且可以基于这种情况建立一些自动失效逻辑。
还必须创建模型来存储由分层导航创建的url，并且这些应该与类别视图url一起失效。
并且在分层导航和无效的情况下，我们必须在保存属性（我认为）时使整个缓存失效。
我们应该能够将产品评论放在产品页面上，而不是为了seo目的而使用ajax。
这意味着保存评论模型时必须使用model_save_before事件进行检查，并且应该使产品页面url无效。 这保存会改变评级，但我建议这个块在ajax调用中被抓住。 这对于seo并不重要。 这适用于产品视图和列表页面。
我们也可以缓存并使浏览模块页面失效，但这对大多数用户并不重要，应该等待。
谁想要标签块。 这些不能由ajax加载它击败他们的目的。 同时他们现在不值得我们的努力。
如果你使用附加的会话ID来缓存url，它会导致用户得到我告诉的每个其他会话。 我认为这很容易通过基于正则表达式的vcl_fetch管道来解决。
这个答案越来越乱，应该很快重新起草。 随时添加您的2美分！
链接地址: http://www.djcxy.com/p/61677.html