Magento Cache-关于Varnish，Redis，APC，Memcache的困惑

我正在尝试改善Magento的性能（“ MageDev”迟早会达到这一点：）

我进行了一些研究，发现很多不错的指南，但并不统一。

我得到的是：

• MemCache或Redis是通用的缓存系统，它们缓存数据，并且可以直接与Magento（local.xml）集成。
• APC是php代码本身的缓存，只能在服务器级别集成。
• Varnish是反向代理，它缓存响应只能在服务器级别集成。（Magento，松节油有扩展名，但我不确定确切是做什么的）

读完所有这些内容后，我仍然对上述哪种缓存系统可以组合使用（例如EX）感到有些困惑：

• MemCache + APC？
• Redis + APC？
• 我可以将Varnish添加到上述配置之一吗？

只是要清楚，问题不是关于如何配置Magento或服务器，而是允许的可能性是什么，以及关于如何混合缓存系统的一些许可。（此外，如果有人可以提出好的建议，我将不胜感激。）

TL; DR-在MageStack上，我们使用Varnish，Redis（缓存），Redis（会话）和Eaccelerator / Zend OPCache（取决于PHP版本）

您已经了解了大部分内容。

缓存后端，会话存储，操作码缓存，全页缓存和反向代理缓存都完全不同。

您可以对所有人使用不同的技术，也可以同时使用所有这些技术（包括清漆和FPC）

缓存后端

• 文件（核心）默认
• 内存缓存（核心）
• APC（核心）
• Redis（<1.9模块，由Colin Mollenhour提供）
• MongoDB（模块由Colin Mollenhour提供）
• 红宝石（由Daniel Sloof提供）

您只能使用一个缓存后端。

与流行的看法相反，使用基于内存的缓存不会提高性能。但这将克服Magento基于文件的默认缓存中的一些致命缺陷。

在撰写此消息时，Redis是我的建议。

会话商店

• 文件（核心）默认
• 内存缓存（核心）
• Redis（<1.9模块，由Colin Mollenhour提供）
• MongoDB（模块由Colin Mollenhour提供）

您只能使用一个会话存储。

与流行的看法相反，使用基于内存的会话存储不会提高性能。

在撰写此消息时，Redis是我的建议。

操作码缓存

• 装甲运兵车
• XCache
• 加速器（PHP <5.4）
• Zend OPCache（PHP> 5.4）

实际上，您可以安装多个操作码缓存，但是不建议这样做，我也不希望看到任何好处。

我的建议在上面的括号中。

无需安装任何模块即可利用此功能。

反向代理缓存

• 漆
• Nginx的
• 阿帕奇
• … 还有很多

您可以使用多个反向代理，尽管这样做很复杂并且易于缓存扩展，但它也有其优点（例如，防止在缓存刷新期间加盖标记）。

必要时使用一个（即，不是为了加快慢速站点，而是减少快速站点上的资源使用）。

为了利用反向代理，它既需要启用服务器端，也需要一个Magento模块。

该模块的原因是帮助控制缓存逻辑（即告诉缓存应缓存和不应该缓存的内容），以及管理缓存内容（即触发缓存的清除）。

除非您完全了解自己的工作，否则我不建议您这样做。设置错误的反向代理可能会破坏标头信息，可能导致会话丢失，会话共享，陈旧的内容，对加载时间/缓冲区施加其他限制，消耗额外的资源等。

全页缓存

• 电子软板
• …其他（通过模块）

必要时使用一个（即，不是为了加快慢速站点，而是减少快速站点上的资源使用）。

与流行的看法相反，您可以（并且应该）将FPC与反向代理缓存一起使用。两者解决不同的问题，具有不同的功能。

FPC可以利用更多的情报，因为它们可以直接访问用户会话和Magento的核心，而反向代理并不了解应用程序（它的工作方式相当愚蠢）-因此两者相互补充，而不是相互竞争。

就是 不要以为Varnish或FPC，而要以Varnish和FPC为例。

我将选择Redis + APC和Varnish。

你问“为什么要Redis”？阅读这个出色的答案。Redis基本上取代了Magento的标准基于文件的缓存系统。由于Redis更快，因此可以提高速度。

实际上，清漆与内部工作关系不大。它放在顶部并缓存静态内容，因此它实际上从未作为请求到达Magento。除了打孔部分。

虽然Varnish仅专注于前端缓存，但Redis还将加快其他类型的缓存，如EAV和配置缓存。

您也可以选择检出Magento的某些Full Page Cache扩展，而不是Varnish。尽管速度不如预期，但通常更易于实现，并且不依赖于其他软件（例如Varnish）