Magento自动缓存见解
https://magento.stackexchange.com/questions/610
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我们正在使用memcache运行Magento EE 1.11。 2GB每个memcahce服务器，总计4GB。我们有大约24万产品。
- 可用RAM：6GB
- 核心：16
- 线程：32
这是交易，添加了更多的新产品，每天都会发生更改产品，当然，每次在后端中添加/修改新产品时，缓存就会无效，特别是“全页高速缓存”。
当启用Magentos Auto Cache生成时，大约需要2天才能建立缓存，并将8个线程分配给爬虫。 2天后，Memcache在两个RAM磁盘之间散布〜2GB。
问题是，当每天修改产品时，高速缓存就会无效，并且一旦“全页高速缓存”刷新了那些2GB的高速缓存，将返回正方形，返回正方形，0，0，Magentos Auto Cache的粘性周期再次开始。现在，缓存不仅回到0，而且CPU使用率达到90％，并且网站变成5-10+秒的等待游戏，您只会忘记尝试请求具有100多个变体的产品，如果是没有缓存，第一次加载需要几分钟，这太荒谬了。
所以，我向社区的问题。
- Magento是否可以自动“更新”缓存，如果无效，则可以自动“更新”缓存，而无需重建整个缓存并从0开始？我知道何时缓存无效，Magento知道Somethings已更改，但在缓存中的位置不完全（如果我错了，请问我）。是否有模块/配置可以绕过整个缓存？
在旁注上，我们使用的是微型砖光模块。
Magentos可以用Cronjob控制自动缓存吗？说，开始于晚上10点至凌晨6点爬行。
处理这种情况的最佳方法是什么？，因为您了解重建每天在千兆字节中的缓存是不可接受的。
解决方案
你没有足够的公羊
我们有大约24万产品
可用RAM：6GB
线程：32
您没有足够的RAM来供您拥有的产品数量。根据逻辑核心，我们建议至少2-4GB RAM。
如果您绘制可能的内存使用量：
- 64个PHP线程
max_memory〜768MB = 24GB - 240,000种产品可能意味着约15GB的InnoDB桌子空间
- 64个PHP线程将保证128个MySQL连接，通常为每个连接的成本约为200mb
- Redis和240,000种产品的后端存储
lzf压缩 - 仍将消耗约6GB的RAM
因此，到目前为止，总数是70GB的持久RAM-我们甚至没有提及操作系统等。
您的硬件是 可怕地指定. 。我建议阅读 Magento服务器设置 文章为如何进步提供了一些感觉。
memcached不支持缓存标签
如果您使用的是memcached（不是问题，它的性能很高），那么您要么存储缓存标签。如果您没有 slow_backend 定义 - 然后您不会存储标签，这基本上意味着您的缓存无法区分任何不同的缓存类型 - 因此您将无法独立冲洗它们。
我们强烈建议切换到Redis。它具有怪癖，并且确实需要大型商店进行大量的微调。但是总体而言，表现会比Memcaching稍微获得缓存标签支持的真正好处。
404和FPC
FPC有一个真正的问题，事实上，所有缓存发动机都有404s的问题。原因是，任何仍被爬行或链接到的旧URL都将降落在必须迭代整个整个的页面上 core_url_rewrite 表，尝试与所有定义的路由器和名称空间找到匹配，然后最终放弃并加载404。
然后缓存一个没有价值的资源，并将在您的缓存存储中消耗空间。您可能会发现大部分备忘录存储实际上是由404个内容食用的。
借助大型目录（240k产品），您肯定会在产品营业额中得到相当大的份额，因此，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时间表。
如果您能负担得起陈旧的内容
最终，如果您有 足够的 内存。您很可能会从增加FPC中存储的内容的TTL中受益 - 以使您的缓存数据存活更长的时间。
在里面 <full_page_cache> 标记您 ./app/etc/local.xml 只是定义
<lifetimelimit>86400</lifetimelimit>
寿命以秒为单位定义。您需要在内容新鲜度，性能和实际可用的存储空间之间取得平衡。
您为什么使用EE使用第三方缓存扩展
您要为FPC支付溢价 - 让我想说的是非常好。那么，为什么要在顶部运行第三方替代方案。 去掉它。
这样说。如果您的汽车运行良好 - 您会在靴子中添加另一个引擎以补偿吗？还是只是修复已经在那里的引擎？
其他提示
我们非常了解您！我们每天添加新的或更改我们的产品，并修改静态块。因此，我们已经充满了无效的Magento Cache，并且这个常数用于系统 - >缓存管理。我们讨厌手动刷新无效的缓存类型的必要性。
然后我们安装了新的 Magento优化器扩展. 。该模块可自动化此过程。它以指定的频率刷新无效/所有缓存类型或冲洗Magento Cache存储。这对我们所有的团队来说都是一个真正的解脱！
该扩展程序的另一个重要功能是，它清洁了会话文件和比X天更老的错误报告。每个人都知道，var/session和var/报告目录的大小可以成千兆字节，这些文件的数量可能超过一百。因此，为了放慢网站的性能，我们设置了一次Magento Optimizer，并忘记了这些目录的定期刷新。
当客户试图登录时，Magento以将废弃的购物车与当前的购物车合并而闻名。从客户的经验和忠诚度的角度来看，这是破坏性的。 Magento Optimizer模块自动删除X天较早的废弃购物车。您也可以在销售时间使用此功能，并限制现有废弃的购物车的时间。
