CE 1.8上的全页缓存-FPC Magento模块?漆?都?


15

因此,在研究Community Edition 1.8的全页缓存时,我有些困惑。我已经实现了两级Redis缓存CDN,已对MySQL的my.cnf进行了调整,以实现最高性能(当然,数据库是在单独的服务器上),并且我有2台服务器在负载均衡器后面托管我们的商店。我要指出的是,在进行初始性能调整之前,我不会立即跳入FPC。

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

直到现在,我还认为它们是两个独立的实体,您可以实现它来帮助您的网站,但是现在我读过的东西似乎暗示了相反的意思。我最初的计划是为Magento 购买“ Warp Advanced Full Page Cache ”模块(我相信以前是“ Tiny Brick Lightspeed FPC”),因为如果价格偏高(如果坦率地说),它似乎是最受欢迎的模块。 ,对于我们公司而言,350美元的价格不算多,尤其是对于它可以做的事情而言)。我本人和我的2位开发人员正在计划学习,以在我们自己的自定义自制主题中正确,完全地实施它,以最大程度地发挥我们的作用。在完成此操作之后,我想我也会考虑实施Varnish-但是,正如我之前所说,我已经理解它们是分开的。

但是,现在,我开始遇到这样的扩展,例如免费的由Varnish提供支持的PageCache,或由Varnish Cache提供支持的Vortex Cache(将近800美元),它们是直接与Varnish一起使用的Magento全页面高速缓存模块。

我对您的问题,堆栈交换,应该如何看待FPC和Varnish?作为独立实体?如果是这样,它们是否互斥?它们是我应该一起实施的同一枚硬币的两个侧面吗?还是它们相似但彼此不排斥也不包容?

我可以将上面提到的Warp Advanced FPC与Varnish一起使用吗? 如果我用清漆使用它?还是如果我打算使用Varnish,最好使用其他FPC?甚至更进一步,是否有FPC这么好以至于我不需要清漆?反之亦然,我应该只使用Varnish放弃FPC的想法吗?

抱歉,文本栏不完整,但是我一直在浏览很多文章,博客和论坛帖子,但无法确定对这些问题的明确答案。非常感谢您的帮助和建议=)

哦,最后,关于Varnish和Web服务器的一个简短问题。目前,我使用的是正常的Apache LAMP堆栈设置,但是一段时间以来,我一直在看到人们热衷于将Nginx与Magento一起使用。我自己做了一些测试,包括压力和负载测试,看来在正确的条件下肯定可以做得更好。因此,我正在考虑在不久的将来切换。无论如何,这会影响我使用FPC和/或清漆的愿望和决定吗?

谢谢!!!

编辑:哦!还有一个快速的问题-由于我在负载均衡器后面托管了两台服务器来托管我的网站(这也是一种设置,可以在需要时进行横向增加),因此我充分利用了Redis和Memcached托管在与服务器不同的服务器上Web和数据库,用于我的会话以及Magento(以及Zend)的二级缓存的每个级别。我假设FPC会将其数据存储到系统之一中?我需要一个特定的扩展名将其存储在此处还是全部由它完成?虽然我认为不会,但这是否会影响Varnish?再次感谢!!


显然,由于缺乏声誉,我只能在文本墙上放置两个链接。鼓励我去互联网点兜风 的方法是什么...就是说,这里是链接: 由Varnish提供支持的Vortex缓存aaand由Varnish提供支持的
PageCache

3
我不能提供有关Varnish的太多建议,但是我建议您看看Lesti FPC-gordonlesti.com/lestifpc它是完全免费的,具有打孔功能,可以通过管理员进行配置。绝对很棒。
Paul

@ThatSourDiesel-您能告诉我们您做了什么吗?最好在接受的答案下,如果您至少将其用于解决方案。
SPRBRN

Answers:


28

计算机科学中有两件困难的事情:

  1. 命名事物
  2. 缓存无效。

打孔属于类别2 :)

一般

最好的方法是从堆栈的较低点开始,并优化直至Magento的前端。


数据库和文件系统

应该永远是第一个重点关注的领域。因为。I / O。

MyTop是一个方便的基于Linux的perl脚本,它将模仿Linux的“ top”命令,并让您深入了解MySQL实例的状态。

Htop更强大的topstrace功能可以帮助确定进程的入/出,以发现潜在的瓶颈。

Iotop是考虑用来监视I / O的另一个工具。

其他方便的实用程序脚本(例如mysqltuner.plmysql tunning入门)可以深入了解MySQL运行时变量并提供帮助建议。请记住,这些只是作为指导,因为最好的方法始终是对需求进行评估并根据收集到的已知数据进行调整。盲目地这样做可能会造成更大的损害。并且过早地运行这些程序而没有至少24小时的mysql运行时变量可能会提供错误的建议。

请记住,Percona,MariaDB和标准MySQL应该与以上所有功能兼容。Magento在InnoDB上是如此繁重,而XtraDB为db引擎提供了许多工具和增强功能,因此将Percona作为MySQL分支很受欢迎。


Apache或Nginx

仍然使用Apache,因为它为许多其他人(包括我自己)提供了很好的服务。我也使用和配置了Nginx。尽管它确实提供了一些优势,但仍存在学习曲线。尽管两者都是很受欢迎的选择,但它确实比Apache提供了一些优势,其中之一是较小的内存空间。但是,运行PHP-FPM的精简版Apache将具有类似的内存占用量。

例子:

由于本文是关于性能的,因此我应该指出,帮助Apache摆脱困境的最简单方法之一是不使用.htaccess文件。将您要放置的内容放在Directory节中,将AllowOverride设置为“ None”,最终您将不会要求apache遍历整个文档路径来确定它是否需要注意.htaccess。这是许多人似乎想念的基本的简单调整提示。

为了帮助进行此检查:

利用CDN来帮助减轻任一个的负担显然会有所帮助,但由于大多数最终用户浏览器将能够以相同数量的连接限制连接到两台服务器,因此在前端优化方面将带来更多好处。这也使Apache不必进行检查,而只需提供简单的静态映像即可。 如果您只想为CDN以外的内容运行静态Web服务器,则可以选择Lighthttpd

的PHP

PHP-FPM和APC。使用它们,剔除Magento不需要的任何不需要或不需要的PHP模块。


Magento代码库

AOE_TemplateHints非常适合确定您的块是否正确缓存:

AOE_Profiler非常适合进行概要分析,请确保并启用其DB层概要分析(显然是在本地/开发环境中)。结合前面提到的mytop工具,使查找不良行为的SQL变得容易。

第三方模块和自定义代码

Magento本身提供了一些非常好的优化最佳实践,这是一本好书,在使用它们之前,请务必仔细阅读第3方模块。(IMO有很多不良行为)。

Magento ECG的Magniffer工具可根据上面提供的PDF轻松帮助识别不良行为代码。它是基于symfony / php-parser的,但是可以通过composer安装。


一个不只是打开清漆

作为Varnish的倡导者,他是FreeBSD内核开发人员,它提供了一些疯狂的亚秒级加载时间。但是,如果您的模板中甚至存在一些细微的差异,但您将花费时间配置清漆/ magento来打孔所需的内容。我见过的大多数人都只会简单地AJAX'化从Varnish中未缓存的所需项目。

有许多Magento模块可以帮助实现这种打孔和缓存:

最终,这应该是优化旅程的最后阶段,并且可能需要进行一些自定义才能使事情正确。


Magento CE FPC

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

它是一个非常好组合(基于观察者)的开源和免费的FPC for Community。


在一天结束时,请使用您自己的测试和判断。

一些进一步的阅读:


2

我知道这个线程有点晚,但是如果您仍在寻找解决方案,那么您可能需要考虑使用Evolved Caching。与Warp的价格相同,但是:

  • 非常快速且易于安装和配置-所有打孔和配置均在管理员内部完成
  • 直接与Varnish集成,使您可以从Magento内部清除和预热Varnish缓存
  • 与Varnish及其自己的缓存中在1.8 CE中引入的前端form_key一起使用。
  • 在响应支持下非常积极地发展。常规新版本,旨在在报告后的几天内发布错误修复
  • 有大量的文档,每个版本都会更新

清漆设置是直线前进,你只需要启用管理员设置和使用.vcl找到这里。当正常情况下不存在Cookie时,您也不受限于Varnish仅提供缓存-您会获得很高的缓存命中率。


哇,有趣。我一定会调查的。我应该在这里发布更新。基本上,我决定使用Varnish而不是使用整个页面缓存模块,但是我对动态部件的处理方法有些犹豫。大多数情况下,ESI与AJAX对比。我尝试了带有松节油的Varnish,但是当我在向购物车添加东西时遇到问题时,我把它拉了。原来问题与我的memcached会话保存处理程序有关,后来我最终找到了。因此,尽管如此,我仍然想备份Varnish,但需要花费一些时间来确保我所有的动态部分都工作正常。
ThatSourDiesel 2014年

1
好吧 由于前端中包含form_key,我认为Turpentine仍不能与1.8 CE一起使用-这可能就是为什么您在添加到购物车时遇到问题。我个人建议在ESI上推荐Ajax,主要是因为ESI要求您在页面交付之前向Magento发送请求,并且这总是很慢。您可能有兴趣查看此帖子。 fabrizio-branca.de/magento-varnish-ajax-vs-esi.html
Jonathan Hussey 2014年

我喜欢Fabrizio的博客!绝对看到了他的AJAX模块-那就是我在我的最后一条评论中提到AJAX时所指的内容。我遇到的“添加到购物车”问题实际上是由于我设法解决的内存缓存怪异。就是说,即使他们说Turpentine不能在1.8上运行,除非您禁用form_key,它似乎对我来说也很好。但是,那时我还没有完全理解ESI,所以自从我禁用ESI以来,直到我可以花更多时间进行实施和测试。我最近错过了一些工作-锁骨断裂,不得不接受手术。
ThatSourDiesel 2014年

顺便说一句,Evolved Caching是您自己的模块?出于好奇-您是否愿意让我试一试我的登台服务器?我们可以在PM域名中讨论什么以及不可以在域名中讨论什么,以便您可以验证它实际上是测试服务器而不是生产服务器=)
ThatSourDiesel 2014年

希望您手术后康复!是的,该模块是由我公司开发的,是的,我们非常乐意让您在暂存/开发域中进行试用。只需使用商店左侧列中的客户服务电子邮件地址给我们发送电子邮件,然后我将其提取-store.husseycoding.co.uk。附带说明一下,很高兴您修复了memcached问题,也许值得注意的是,添加到购物车的用户似乎可以在1.8版以下工作,因为该用户也缓存了其表单键,但导致页面要缓存,但是请清除cookie以获取新的会话+表单密钥,您可能会发现它失败。
乔纳森·侯赛

1

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

BOOMER很好地介绍了从堆栈低处开始并逐步上升的过程。FPC或清漆应该是您的最后操作。我们进行性能审核,通常会发现MySQL和APC配置确实存在的问题。就像Innodb的缓冲区大小设置为默认值一样,数据库已经超出了它。

我们建议不要将任何FPC与Varnish一起使用,除非经过专门设计可一起使用。通常,除非您有一些功能强大的服务器,这些服务器都已与代码库一起进行了调整,但仍在努力保持流量,否则我们不建议您使用Varnish。使用Varnish更新动态内容可能会有些棘手,特别是在尝试将您的请求限制到Magento后端并进而减少负载时。如果您有一个或两个Web主管,则获得的收益可能不值得花费时间和复杂性。

在大多数情况下,良好的FPC当然可以在调整服务器和代码库之后为您提供所需的性能。使用我们的FPC,您可以在1级缓存中获得15毫秒以下的生成时间,在标准缓存中获得100毫秒以下的生成时间。我们的1级缓存用于用户未登录且购物车中没有任何东西(因为它不打孔)的情况。当这些条件中的任何一个为假时,标准高速缓存将与完整的打孔支持一起使用。

我们的FPC内置了方便的打孔功能,并且可以与所有标准Magento块以及您可能拥有的任何自定义块一起使用。所有这些都可以通过管理面板进行配置。

我建议您坚持使用Redis,除非您遇到伸缩问题。它具有标签支持,并且比以文件或数据库作为慢速后端的memcached快得多。如果您想要一致的标签并进行清理,那么当您有多个Web头时,必须对数据库使用memcached。内置Redis的标签支持后,您不必担心。您还可以将Redis用于会话。

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


可以保证不到20毫秒的时间传送到浏览器。我见过只有Magento FPC在真实的现场商店中完成。
梅尔文2015年

0

没有正确的答案。商店应具有3s以下的动态页面加载,理想情况下应具有1-2s的动态页面加载,亚秒级不是必需的,并且主要是市场营销驱动的统计信息。Apache易于学习且难以执行,Nginx难以学习且易于执行,许多站点都移至Nginx,但是要拥有基于Nginx和Magento的高质量架构并不简单。

多服务器Magento集群的实施已经很复杂,如果没有正确的体系结构,则维护起来会更加困难,我们通常会使用较大的集群,这使得包括排名在内的所有运行都更加流畅。我们使用标准安装配置进行此操作,并针对中长期稳定性进行了较小的更改,以1-2s动态页面加载为目标,这使得维护变得更加简单。

清漆可以是FPC,CDN等,但是在您的情况下,最好将其视为FPC。FPC允许服务器上有更多访问者,并提供更快的静态交付,而Varnish就是其中一种工具,但是它存在很多问题,包括动态内容,库存控制,定价。答案归结为企业的结构,数据的加载方式,频率,托管类型等等,这仅仅是向访客提供静态内容而对企业造成的影响。您可以使用FPC config从技术上缓解很多问题,但是它会使业务环境复杂化,从业务所有者的角度来看,它可能不会产生平衡的投资回报。

FPC是最后一部分,如果您具有3s或更佳的动态负载,则您的体系结构可以处理访问者请求中的串扰,因为这会影响排名,吸收营销和假期高峰,并有预算增加服务器体系结构的复杂性-托管应为0.5小型企业收入的-1%,大多数企业在此基础上运营,从而导致许多间接业务问题。

您找不到确切答案的原因是由于这些问题是定性的(基于业务)需要几个月的时间才能回答,因此需要公司不想公开发布的信息,页面加载速度是定量的(基于技术) )(可以公开发布),这是您将两者结合起来构成解决方案的方式。


-2

您可以使用此Magento页面缓存来满足您的需求,该缓存类似于清漆。许多最大的Magento商店都使用它。一些功能:

  1. 像Varnish一样,对于90%的请求,它也不使用数据库连接。结果,它非常快
  2. 它具有在产品库存等发生变化时自动刷新页面的功能,非常擅长
  3. 它是一个多层缓存,因此在用户登录时也支持打孔(这些请求需要使用数据库)

作为多级缓存,它甚至可以扩展到流量最高的商店,并且已经在许多流量高峰的站点上使用,这些站点会收到高峰流量,例如SharkTank上的商店(电视节目)


这没有回答作者是否应使用清漆或FPC的问题。
史蒂夫·罗宾斯

如果您是产品的作者,则必须披露@extendware。我们欢迎您做出宝贵的贡献,但我们不欢迎垃圾邮件。
philwinkle
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.