magento 开源整页缓存答案

【问题标题】：magento open source full page cachemagento 开源整页缓存
【发布时间】：2012-10-25 20:22:02
【问题描述】：

我最近与一位开发人员交谈，他说即使使用默认安装，也没有任何 magento CE 整页缓存可以完美运行。

我的经历是一样的。

如果您使用 aoe_static 的出色模块和 phoenix 的全页缓存和 varnish 模块，您将接近。

使用 aoe_static 模块缓存是在每个动作的基础上完成的，这对我来说似乎是明智的。打孔是通过布局 xml 应用的占位符和通过不会被缓存的 ajax 调用请求的动态块来完成的。 cookie 也通过此调用设置。他提供了一个默认的 vcl，它适用于 varnish 2（我从未检查过），并且可以很容易地更改为 varnish 3。

phoenix 模块很好地处理了缓存失效。您可以在模块的控制文件夹中看到方法。这会在产品或类别更改时处理缓存失效，并使产品页面和类别页面都失效。但是，分层导航生成的 url 可能会被缓存（取决于您的 vcl）。这些都没有失效，所以要小心。

在我将它们用于生产站点之前，我真的很想知道这些模块是否存在任何其他问题。如果有人能指出我的问题，我很乐意尝试发布解决方案。

但是对于分层导航 url，需要一个模型来记录生成的带有类别 ID 的 url。我想拥有一个 2 列模型（url 和类别）会很简单，然后缓存失效需要检查模型并使额外的 url 失效。这应该在主类别 url 完成的同时完成。听起来还不错。如果有人得到我非常简短的解释，请在我浪费时间之前告知我是否遗漏了什么。

我宁愿在一些社区帮助（或更有经验的领导者）的帮助下创建一个开源项目，至少在默认的 1.7 安装中具有（当之无愧的）可靠性声誉。我认为最明智的做法是创建一个包含或记录所有边缘案例（对于默认的 1.7 安装）的模块。

有人知道如何执行这样的任务吗？如果有更多的社区支持使用 apc 或 memcached 执行此操作，那么对于更广泛的托管可用性可能更明智。逻辑或开发时间不会有太大变化。

这可以扩展以涵盖应该牢记的块的会话缓存，但我认为关注可靠的全页缓存应该是优先事项。

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

我已经为这个项目创建了一个电子邮件，所以如果你想参与它是“magefpc gmail com”。任何有 magento、git 和调试经验的人都会受到欢迎。

谢谢

【问题讨论】：

不是一个真正的答案，但我们已经在许多网站上使用了 Phoenix mouldule，并围绕基于某些事件打开/关闭缓存进行了一些扩展，并引入了一个基于 cookie 的系统用于维护一些用户数据客户端。我们在github.com/aligent/Phoenix_VarnishCache 维护我们的模块版本的公共GitHub 存储库......我们还看到（但未使用）Nexcess 的Turpentine 模块（github.com/nexcess/magento-turpentine）。 Turpentine 的实现要简单得多，而且看起来很有趣。我们很乐意尽我们所能提供帮助。
非常感谢您的报价！我查看了您的代码，它看起来很合理，但采用了非常不同的方法。我相信我们应该等待几周才能看到更多变化并权衡利弊。无论如何，分层导航 url 需要失效，但我相信应该绑定到一个完整的模块
我想多了，得出的结论是我真的很喜欢使用phoenix 模块和aoe_static 的模块。就像我说的那样，您对动态内容的处理方式非常不同。但是，您与 AW 博客的集成是一个绝妙的主意，对大多数企业来说都是必不可少的。我真的认为重构这些元素并将我描述的缓存失效添加到一个模块中是一种好方法。我想检查其他模块的创建者是否对此感到满意并试一试。你认为呢？我们现在似乎独自在这个问题上:(
Phoenix 模块是 OSL 许可的，所以应该没有问题，我认为 aoe_static 是一样的。我没有看过 aoe_static，但我们在我们做的大多数网站上都使用 aoe_scheduler，它非常棒。
是的，他是个很酷的人，而且在 aoe_static 模块上甚至没有许可证。这个想法对我来说似乎很合理，但需要一些工作和大量测试。我认为以这种方式构建的连贯的单个模块很容易适应大多数商店。是否需要比迄今为止基本描述的更多的工作？

标签： magento caching

【解决方案1】：

您可能对 aoe_static 遇到的问题是，目前该扩展程序不记录产品，因此后端中有关已查看产品的统计信息不会更新。这是最近作为 TODO 注释添加到 github 中的。

清漆和magento缓存的问题是，magento缓存部分页面、块和清漆确实缓存了整个页面。因此，即使 phoenix 解决方案有适当的观察者并在产品/类别更新时相应地重置清漆，您仍然在 magento 中有块必须重置。 aoe_static 试图解决这个问题，但它只适用于页面上的可见块。但是magento的其他部分，作为分层导航，可能会在产品/类别更新内部重置，但不会在清漆中重置。有2个解决方案。要么识别前端的magento的每个部分，在产品/类别更新后没有重置，然后对其应用aoe_static解决方案。这意味着您必须通过 ajax 加载分层导航。或者第二种解决方案是，在 phoenix 扩展中添加更多逻辑以使更多清漆页面无效。

我有几个自定义扩展（显示产品的页面），并且我构建逻辑以在每次更新产品/类别时使这些扩展无效。现在我正在研究搜索，因为这也需要失效，但复杂的部分是，解决块和缓存失效逻辑。

总体而言，正确的缓存失效是 Web 开发中最困难的部分之一。

【讨论】：

您的帖子似乎重要且准确。这样做的最终结果将是重复访问服务器。这是负载平衡设置的一个昂贵但易于管理的问题。如果我们以更全面的方式管理 aoe_static 和其他模块的想法，我们将获得可靠缓存响应的预期结果（我希望如此）。就像你说的那样，这是一个困难的领域，但社区会一次又一次地遇到。我认为以社区方式处理这个问题要好得多，因为有许多人在 git 上添加和分支的经验。我还不想缓存搜索。
我想起了 Phil Karlton 的一句话：“计算机科学中只有两件难事：缓存失效和命名。”
big style :) 但是这么多人使用它，ajax 请求和负载均衡服务器的逻辑大大减少了我们的困难。只要采取综合方法，就可以存在非常可靠的模块。我实际上对编程很陌生。起初我对可以做的事情感到惊讶，现在我对推送到生产环境的内容感到震惊，并且绝对拒绝发布一半完成的工作。看看SO上详述的FPC问题，很多都是终端用户遇到的问题！！
我对 aoe_static 的唯一问题是，在每次 ajax 请求时，它都会初始化整个 magento 应用程序以生成块。在这样做的同时，magento 做了很多不必要的（当时）数据库和文件请求。所以最后它在服务器上产生与未缓存请求几乎相同的负载。好处是，用户通过清漆更快地获得页面的主要部分，稍后再获得动态部分。你也应该用这种方法从谷歌获得更好的分数。
我在第一条评论中说“重复访问服务器”哎呀。无论如何，我现在没有看到任何需要。动态内容可以在一个请求中处理，这会给您的数据库带来压力。只需要将占位符和产品信息发送到服务器进行一次调用即可处理。这有点尴尬，但还不错。使用观察者，设置带有产品信息的 cookie，在 vclhash 中附加 cookie 并在 vcl_deliver 中设置。这里是早上 5 点。这可能行不通

【解决方案2】：

我希望这篇文章成为一个社区答案，详细说明特定句柄的方法以及建议的缓存和失效逻辑（如果它尚未包含在 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 包含，而不是像通常那样包含在管理员所见即所得中。这些小部件可以添加到呼叫控制器句柄和占位符到任何需要的句柄。

全清漆失效，有时，不是床的事。如果它发生得太频繁，或者如果它在需要时没有发生，那么整个缓存失效是一个问题。主要目标应该是捕获每个失效场景并在管理面板中触发通知，与您保存产品时收到的相同类型的消息：“一个或多个缓存类型失效......” 这样，管理员可以决定是否要手动使缓存无效或等待。并且ofc可以根据这种情况内置一些自动失效逻辑。

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

考虑到分层导航和失效，我们必须在保存属性时使整个缓存失效（我认为）。

我们应该能够在没有 ajax 的情况下将产品评论放在产品页面上，以达到 seo 的目的。

这意味着当保存评论模型时，必须使用 model_save_before 事件检查它，并且我们应该使产品页面 url 无效。此保存更改了评级，但我建议在 ajax 调用中获取此块。这对 seo 来说并不重要。这适用于产品视图和列表页面。

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

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

如果您缓存附加了会话 ID 的 url，它将导致用户获取彼此的会话，我被告知。我认为这很容易通过基于正则表达式的 vcl_fetch 管道解决。

这个答案越来越混乱，应该很快重新起草。随意添加您的 2 美分！

【讨论】：