CE 1.8 上的全页缓存 - FPC Magento 模块？漆？两个都？

magento.stackexchange https://magento.stackexchange.com/questions/13957

题

因此，当我开始研究 Community Edition 1.8 的全页缓存时，我有点困惑。我已经实现了两级 Redis 缓存、CDN，调整了 MySQL 的 my.cnf 以实现最大性能（当然，数据库位于单独的服务器上），并且我有 2 台服务器在负载均衡器后面托管我们的商店。我这样说是为了指出，在进行初始性能调整之前，我不会立即转向 FPC。

我以前从未在任何类型的网站上使用过 Varnish，更不用说 Magento，而且我也从未在 Magento 中设置过 FPC。我认为 Varnish 是一个代理，充当 CDN 和页面缓存之间的交叉点，在请求到达 Web 服务器之前将数据发送到浏览器。据我了解，FPC 模块在本地创建一个缓存，由网络服务器本身提供。我知道对于这两种设置，您都需要进行一些“打孔”才能将动态内容传递到浏览器（尽管使用模块或使用 Varnish 之间的技术不同）。如果我在这里有任何误解，请纠正我。

到目前为止，我认为它们是两个独立的实体，您可以实现它来帮助您的网站，但现在我读到的一些内容似乎暗示着相反的情况。我原来的计划是买“Warp 高级全页缓存Magento 的模块（我相信以前是“Tiny Brick Lightspeed FPC”），因为它似乎是最受欢迎的，如果价格稍贵一点的话（但是，坦率地说，350 美元对我们公司来说并不算多，特别是对于它可以做到）。我自己和我的两位开发人员同事正计划学习如何在我们自己定制的自制主题中正确、完整地实现它，以最大限度地发挥我们的作用。完成之后，在未来的某个时刻，我想我也会考虑实施 Varnish - 但是，正如我之前所说，我已经理解它们是分开的。

然而，现在我开始遇到这样的扩展，比如免费的 PageCache Powered by Varnish，或者这个 Vortex Cache Powered by Varnish Cache，价格接近 800 美元，它们是直接与 Varnish 一起使用的 Magento 全页缓存模块。

我的问题是，堆栈交换，我应该如何看待 FPC 和清漆？作为独立的实体？如果是这样，它们是相互排斥的吗？它们是同一枚硬币的两面，我应该一起实施吗？或者它们相似但既不排斥也不包容？

我可以将上面提到的 Warp Advanced FPC 与 Varnish 一起使用吗？ 应该 我和清漆一起使用吗？或者如果我打算使用 Varnish，使用不同的 FPC 会更好吗？或者更进一步，是否有 FPC 如此好以至于我不需要 Varnish？或者反之亦然，我应该只使用 Varnish 并放弃 FPC 的想法吗？

抱歉，文字墙很长，但我一直在查看大量文章、博客和论坛帖子，但我无法辨别这些问题的明确答案。我非常感谢您在此事上的帮助和投入 =)

哦，最后，一个关于 Varnish 和网络服务器的简单问题。目前我正在使用普通的 Apache LAMP 堆栈设置，但有一段时间我看到人们热衷于将 Nginx 与 Magento 一起使用。我自己做了一些测试，压力和负载测试，看起来它在合适的条件下肯定可以工作得更好一些。因此，我正在考虑在不久的将来的某个时候进行转换。这是否会影响我使用 FPC 和/或清漆的愿望和决定？

谢谢你！！！

编辑：哦！还有一个简单的问题 - 由于我有两台服务器在负载均衡器后面托管我的网站（这也是一种可以在需要时水平增加的设置），因此我充分利用了托管在独立服务器上的 Redis 和 Memcached我的会话的 Web 和 DB 以及 Magento（以及 Zend）的每一级二级缓存。我假设 FPC 会将其数据存储在其中一个系统中？我是否需要一个特定的扩展来将其存储在那里，还是他们都这样做？虽然我认为不会，但这会影响 Varnish 吗？再次感谢！！

有帮助吗？

解决方案

计算机科学有两件事：

  1. 命名
  2. 缓存无效。

孔打孔属于2类:)

一般的

最好的方法是从堆栈的下部开始并优化到Magento的前端。

数据库和文件系统

应该始终是第一个关注的领域。因为。我/o。

mytop 是一个基于方便的Linux Perl脚本，它将模仿Linux“ Top”命令，并让您了解MySQL实例的状态（S）。

HTOP 是一个 更健壮的顶部, ， 这 strace 功能可以帮助确定一个过程以找到潜在瓶颈的过程。

iotop 是考虑监视I/O的另一种工具。

其他方便的实用脚本，例如 mysqltuner.pl 和 MySQL TUNNING PRIMER 可以洞悉您的MySQL运行时变量，并提供建议。请记住，这些是指向指南，因为最好的方法始终是根据收集的已知数据对要求和调整进行评估。盲目这样做有时会造成更多的伤害。并且在没有至少24小时的MySQL运行时变量的情况下过早运行这些建议可能会提供不好的建议。

记住 Percona, ，Mariadb和Standard MySQL应该与以上所有内容一起使用。偏爱Percona作为MySQL叉子，因为Magento在InnoDB和Xtradb上非常沉重，为DB引擎提供了许多工具和增强功能。

apache或nginx

仍在使用Apache，因为它已经为许多其他人提供了很好的服务，其中包括我自己。我也使用并配置了nginx。虽然确实提供了一些优势，但有学习曲线。虽然这两个都是流行的选项，但它确实具有与Apache相比的一些优势，但其中一个将是一个较小的内存足迹。但是，运行php-fpm的纤细的apache将具有类似的内存足迹。

例子：

由于本文是关于性能的，因此我应该指出，帮助Apache脱离其方式的最简单方法之一就是不使用.htaccess文件。将您放在目录节中的内容，将AllowOverride设置为“无”，您最终不要求Apache穿越整个文档路径，以找出是否需要注意.htaccess。这是许多人似乎错过的基本简单调整提示。

为了帮助促进此检查：

使用CDN来帮助脱颖而出，这显然会有所帮助，但会在前端优化方面增加好处，因为大多数最终用户浏览器都可以连接到具有相同数量连接限制的两个服务器。这也使Apache不必跳过检查，而只是为了提供简单的静态图像。 lighthttpd 如果您想在CDN以外的内容运行静态Web服务器，则是一个选择。

php

PHP-FPM和APC。使用它们，剥离Magento不需要的任何不需要或不需要的PHP模块。

Magento代码库

aoe_templatehints 非常适合确定您的块是否正确缓存：

AOE_PROFILER 非常适合分析，确保并启用其DB层分析（显然在本地/开发环境中）。这与 mytop 前面提到的工具使发现不良行为SQL成为更轻松的任务。

第三方模块和自定义代码

从Magento本身进行优化的一些非常好的最佳实践是一本很好的阅读，并且在使用之前审查第三方模块时要牢记。 （有很多行为不良的IMO）。

来自Magento ECG的工具放大器将有助于根据上述PDF轻松识别不良行为代码。但是，它是基于Symfony/PHP-Parser，但可以通过作曲家安装。

漆

one does not simply turn on varnish

作为作者的倡导者是FreeBSD内核开发人员，它提供了一些疯狂的次级加载时间。但是，如果您甚至在模板上遇到了一些丝毫差异，那么您将花费时间配置清漆 /洋红色来对所需的内容进行整理。我见过的大多数人都会简单地将所需的物品从清漆中删除。

有许多Magento模块可以帮助促进这种孔打孔和缓存：

最终，这应该是您优化旅程的最后一端，并且 可能 需要一些自定义才能使事情正确。

Magento CE FPC

到目前为止，我发现最好的CE FPC是：Lesti :: FPC

这是一个非常好的组合（所有基于观察者）的开源和免费的FPC。

归根结底 使用自己的测试和判断。

一些进一步的阅读：

其他提示

我知道这个线程有点晚，但是如果您仍在寻找解决方案，那么您可能需要考虑， 进化的缓存. 。它的价格与翘曲相同，但是：

  • 非常快速，易于安装和配置 - 所有孔打孔和配置都是从管理中完成的
  • 直接与清漆集成，使您可以从Magento内部清除和加热清漆
  • 与1.8 CE中引入的前端Form_key一起工作，并在清漆和它自己的缓存中使用。
  • 在响应支持方面非常积极地发展。定期新版本，目的是在报告后的几天内发布错误修复
  • 广泛 文档 每个版本都会更新

使用Varnish设置很简单，您只需要启用管理设置并使用.VCL找到 这里. 。您也不仅限于在没有cookie的情况下按照正常出现cookie时仅限于清漆 - 您会获得很高的高速缓存命中率。

我们编写了一个与 Magento 1.8 新表单密钥兼容的 FPC。Brim 的整页缓存： http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER 提出了一个很好的观点：从低层开始，然后逐步向上。FPC 或清漆应该是最后做的。我们进行性能审核，通常会发现 MySQL 和 APC 配置确实存在问题。就像 Innodb 缓冲区大小设置为默认值一样，数据库的增长远远超过了它。

我们建议不要将任何 FPC 与 Varnish 一起使用，除非专门设计用于协同工作。一般来说，我们不推荐 Varnish，除非您有一些强大的服务器，这些服务器都已根据您的代码库进行了调整，并且仍在努力跟上流量。使用 Varnish 更新动态内容可能会很棘手，特别是当试图限制对 Magento 后端的请求并进而减少负载时。如果您只有一两个网络头，那么所获得的收益可能不值得花费时间和复杂性。

在大多数情况下，良好的 FPC 将为您提供所需的性能，当然是在您的服务器和代码库经过调整之后。借助我们的 FPC，您可以在 1 级缓存上获得低于 15 毫秒的生成时间，在标准缓存上获得低于 100 毫秒的生成时间。我们的 1 级缓存用于用户未登录且购物车中没有任何内容的情况，因为它不进行打孔操作。当这些条件中的任何一个为假时，标准缓存将与全打孔支持一起使用。

我们的 FPC 内置了简单的打孔功能，开箱即用，可与所有标准 Magento 块以及您可能拥有的任何自定义块一起使用。这一切都可以通过管理面板进行配置。

我建议坚持使用 Redis，除非您遇到扩展问题。它具有标签支持，并且比以文件或数据库作为慢速后端的 memcached 快得多。如果你想要一致的标签和清理，当你有多个网络头时，你必须将 memcached 与数据库结合使用。由于 Redis 内置了标签支持，因此您不必担心。您还可以在会话中使用 Redis。

我可以代表所有 FPC，但对于我们的 FPC，您可以通过管理员配置存储它的位置。您可以选择使用默认的 Magento 缓存后端或指定自定义设置以使用文件、数据库、APC、Redis、Memcache 和优化文件后端。

没有正确的答案。商店应具有Sub 3S动态页面负载，理想情况下应有1-2S动态页面负载，不需要子秒，主要是营销驱动的统计数据。 Apache易于学习，并且很难表现，Nginx很难学习并且易于执行，许多站点正在转移到Nginx，但是要获得基于Nginx的高质量体系结构，而Magento并不简单。

多服务器洋红色群集已经很复杂，甚至更难维护在正确的体系结构上，我们通常会使用较大的群集，这使得一切都更加顺利地运行，包括排名。我们使用标准安装配置进行此操作，并针对1-2S动态页面负载的中长期稳定性进行较小的更改，这使维护的所有内容都变得更加简单。

清漆可以是FPC，CDN等，但是在您的情况下，最好将其视为FPC。 FPC允许服务器上更多的访问者，并提供更快的静态交付，其中包括一个这样的工具，但是它有各种问题，包括动态内容，库存控制，定价。答案取决于您的业务如何结构，数据的加载方式，托管类型的频率，更多，您的业务仅通过向访问者提供静态内容而影响您的业务。从技术上讲，您可以通过FPC配置来减轻其中的大部分，但是从企业主的角度来看，它使业务环境变得复杂，它可能不会产生平衡的投资回报率。

FPC是最后一部分，如果您有第3次或更好的动态加载，则您的体系结构可以处理访客请求中的Beadth，因为这会影响排名，吸收营销和度假峰值，并且有预算以增加服务器架构中的复杂性 - 托管应为0.5较小企业的收入的-1％，大多数在此造成了许多间接的业务问题。

您之所以没有找到明确答案的原因是由于这些问题需要几个月的时间来回答，因为它们是定性的（基于业务），这些信息需要公司不想公开发布的信息，因此页面负载速度是定量的（技术性的（技术） ）可以公开发布的，这是您的组合方法的结合方式。

你可以使用这个 Magento Page Cache 这将适合您的需求，类似于清漆。它被许多最大的洋红色商店使用。某些功能：

  1. 像清漆一样，它不利用90％请求的数据库连接。结果，它非常快
  2. 当产品库存之类的东西变化时，它具有自动浮游页面的能力，并且非常擅长
  3. 这是一个多层缓存，因此在用户登录时也支持孔冲孔（这些请求需要数据库使用）

作为一个多层次的缓存，即使是最高的交通商店，它也可扩展，并且已在许多接收高峰流量的极高交通网站上使用，例如在Sharktank上展出的商店（电视节目）

许可以下： CC-BY-SA 和 归因
scroll top