Magento自动缓存洞察

我们正在使用memcache运行Magento EE 1.11。每个memcahce服务器2GB，总计4GB。我们有大约24万种产品。

• 可用内存：6GB
• 核心数：16
• 线程：32

这是一笔交易，每天都会添加更多新产品，并且每天都会对产品进行更改，当然，每次在后端添加/修改新产品时，缓存都会失效，特别是“全页缓存”。

启用Magentos自动缓存生成后，大约需要2天的时间来建立缓存，并为抓取器分配了8个线程。2天后，内存缓存在两个ram磁盘之间约2GB左右浮动。

问题是，每天对产品进行修改时，缓存将变得无效，并且一旦刷新“全页缓存”，这些2GB的缓存就会恢复为1到0的平方，并且Magentos自动缓存的粘性周期再次开始。现在，不仅缓存恢复为0，而且CPU使用率飙升至90％，网站变成等待5-10 +秒的等待游戏，您可以忘记尝试请求具有100多种版本的产品，如果没有缓存，第一次加载需要几分钟，这太荒谬了。

所以，我对社区的提问。

• Magento是否有一种方法可以在无效时自动“更新”缓存，而无需重新构建整个缓存并从0开始？我知道缓存无效时，Magento知道某些内容已更改，但不完全是缓存中的什么地方（如果我错了，请纠正我）。是否有模块/配置可以绕过整个缓存的重建？

在侧面说明中，我们正在使用Tiny Bricks LightSpeed模块。

• Magentos自动缓存生成可以通过cronjob进行时间控制吗？说，从晚上10点-早上6点开始爬行。

• 解决这种情况的最佳方法是什么？，正如您所了解的那样，每天重建一个千兆字节的缓存是不可接受的。

您没有足够的RAM

我们有大约24万种产品
可用内存：6GB
线程：32

您所拥有的产品数量几乎没有足够的RAM。根据经验，我们建议每个逻辑内核至少有2-4GB的RAM。

如果您确定可能的内存使用量：

• 64个PHP线程，max_memory〜768MB = 24GB
• 240,000种产品可能意味着约15GB的InnoDB表空间
• 64个PHP线程将保证约128个MySQL连接，通常每个连接的最低成本约为200MB
• 使用Redis并lzf压缩后的240,000产品的后端存储-仍会消耗约6GB的RAM

因此，到目前为止，总共有70GB的已承诺RAM –我们甚至都没有提到OS等。

您的硬件严重不足。我建议阅读此Magento服务器设置文章，以期对如何前进有所了解。

Memcached不支持缓存标签

如果您使用的是Memcached（这不是问题，它的高性能），那么您是否在存储缓存标签。如果您没有slow_backend定义-那么您就不会存储标签，这基本上意味着您的缓存无法区分任何其他不同的缓存类型-因此您将无法独立刷新它们。

请仔细阅读以下内容，http：//www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

我们强烈建议切换到Redis。它有其怪癖，并且确实需要对大型商店进行大量的微调。但是总体而言，由于具有缓存标签支持的真正优势，其性能将比Memcached稍好。

404和FPC

实际上，FPC确实存在问题，所有缓存引擎的404都有问题。原因是，任何仍在爬网或链接到的旧URL都将落在必须迭代整个core_url_rewrite表的页面上，并在最终放弃并加载404之前，尝试找到与所有已定义的路由器和名称空间的匹配项。

然后缓存没有价值的资源，这将占用缓存存储空间。您可能会发现您的Memcached存储中有很大一部分实际上被404内容吞噬了。

有了大型目录（24万种产品），您肯定会在产品营业额中获得应有的份额，因此URL以及随后的许多404都有变化。

FPC无效与清洁

目前（默认情况下），FPC的行为是清除更改后的缓存，而不仅仅是使缓存条目无效。我们编写了一个扩展程序来更改此行为，以使EE商店完全满足您的要求。

这是一个快速补丁，可让您了解如何解决问题。

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

不要运行搜寻器

如果您的足迹足够不错-我们不建议您运行抓取工具，它会产生不必要的负载。浏览该站点的人员/漫游器/爬网程序应保持启动状态。

但是要回答您的问题，如果您查看上述配置文件-您会看到为爬网浏览窗口定义的cron计划。

如果您负担得起过时的内容

最后，如果您有足够的钱 RAM。您可以从增加FPC中存储的内容的TTL中受益，从而使缓存的数据保持更长时间的活动。

在<full_page_cache>您./app/etc/local.xml刚刚定义的标签中

<lifetimelimit>86400</lifetimelimit>

寿命以秒为单位定义。您需要在内容的新鲜度，性能和实际可用的存储空间之间取得平衡。

为什么在EE中使用第三方缓存扩展

您为FPC支付了溢价-我很难说，这非常好。那么，为什么要在顶部运行第三方替代方案呢？去掉它。

这样说。如果您的汽车行驶不佳-您是否会在后备箱中添加另一个引擎来进行补偿？还是只是已经修理好引擎了？

我们非常了解您！我们每天都会添加新产品或更改产品，同时还会修改静态模块。因此，我们已经用完了无效的Magento缓存，并将此常量转到系统->缓存管理中。我们讨厌必须手动刷新无效的缓存类型。

然后，我们安装了新的Magento Optimizer扩展程序。该模块可自动执行此过程。它刷新无效/所有缓存类型或以指定频率刷新Magento缓存存储。这对我们所有团队来说都是一次真正的解脱！

此扩展的另一个重要功能是，它清除了X天之前的会话文件和错误报告。每个人都知道var / session和var / report目录的大小可以增长到千兆字节，并且这些文件的数量可以超过一百。因此，现在为了降低网站性能，我们一次设置了Magento Optimizer，却忘记了定期刷新这些目录。

Magento以在客户尝试登录时将废弃的购物车与当前的购物车合并而闻名。从客户的经验和忠诚度的角度来看，它具有破坏性。Magento Optimizer模块会自动删除X天之前废弃的购物车。您也可以在销售时使用此功能，并限制现有废弃推车的时间。