预热Magento企业全页缓存

19

Magento Enterprise中全页缓存的性能优势是众所周知的。可能不那么为人所知的是，要实现此功能的全部好处，必须将其完全填充并热销，尤其是在没有几页的大型产品集上，从而利用自然流量准备足够快。

Magento包含一个内置的cronjob，可用于清晨爬网并为FPC加热。

我已经看到和听说过由清晨工作花费太长时间来运行，导致其他工作无法运行而导致的问题，并且我想知道其他人会使用或建议使用它来完成此工作。我有几个想法是：

  • 组合一个Shell脚本以爬网所生成站点地图文件中的每个页面。
  • 使用单独的crontab条目和简短的PHP脚本来引导Magento并直接执行搜寻器过程。

欢迎对此有任何想法和/或经验！

performance  cache  magento-enterprise  full-page-cache  cron 
— 大卫·阿尔格
source
1
实际上，您可以从单独的文件调用Enterprise搜寻器，并使用服务器crontab触发它，这样就不会造成麻烦。
— Toon Van Dooren 2013年

Answers:

16

可以将siege与sitemap.xml文件结合使用，就像MageSpeedTest一样。

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

然后跑

siege -i -c 1 -t 7200s -f urls.txt

内容来自这里。

— 阿什莉·施罗德（Ashley Schroder）
source
您还可以使用–delay
— Ben Lessani-Sonassi，2013年
注意：这些sed命令在Darwin上不起作用，但在CentOS上起作用。
— davidalger
1
这不能保证每个网址都会被“温暖”。围攻将随机选择要从文件中命中的URL，但不一定访问每个URL。
— Joe Constant
22

我们只是没有-根本没有。曾经 我们会一遍又一遍地说

缓存！=性能

您的站点需要快速而无需添加FPC（或为此使用Varnish）。总会有一段时间内容没有准备好（您的上述情况）。

在无货商店中，使用FPC进行页面加载的时间不会比非FPC印象深刻。Magento很高兴能够< 400ms在标准缓存（类别/产品/搜索页面）上加载页面。FPC会将其降低到< 80ms-但有一些警告。

  1. 库存/价格信息已过期，直到失效或TTL到期为止

  2. 新项目/更相关的搜索已过期，直到失效或TTL到期

    等等

为什么依赖FPC（或清漆）是个坏主意

如果您要继续确保手动填充缓存，则可能有一些原因

  1. 您没有足够的自然资源来保持缓存的就绪状态（请参阅“ FPC有用之处”）
  2. 没有它们，您的网站速度太慢

您无法缓存所有内容

如果您的商店只有5个类别，则嵌套2级深度，5个可过滤属性，每个5个属性选项和1000种产品；这是很多可能的组合。

25种选项可供选择，连续最多选择5次- 我不是统计学家，但我知道那是...（假设属性选项的数量没有完全减少）

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

好的，如我所想，上述情况不太可能发生，只需单击3次-可用产品的数量将减少得足以让客户找到他们的产品。所以即使是...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations

然后将其乘以5个类别，即625个URL。在这个阶段，我们正在谈论一个很小的目录，而完全忽略了所有产品URL。

我们也没有考虑到，如果您is_anchor启用了嵌套类别，则类别将成倍增加。

因此，要抓取大量页面-您要么希望您的页面加载时间一开始就不错，而且很短，所以这是一个快速的轻量级过程（因此破坏了抓取的目的）-或者您已经在TTL过期之前有足够的时间完成它。

如果您的页面的页面加载时间为0.4s，并且您有8核CPU-那么...

625 * 0.4 = 250 / 8 = 31 seconds

0.5分钟，还不错-但让我们假设您的页面加载时间为2秒

625 * 2 = 1250 / 8 = 156 seconds

但是，如果您采取了最大可能的方案

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

这就是您的生产服务器，在100％CPU负载下持续15分钟。您将按比例减小爬网速度，使其与所需的TTL成比例。

因此，如果您希望内容具有3600s TTL，则抓取速度可能会慢4倍-即。仅25％的CPU用于抓取。仅仅是为了使类别内容保持最佳状态，这是很多资源-我们目前还没有考虑产品，搜索字词或其他商店视图的因素

实际上，只要查看catalog_url_rewrites表中组合的绝对大小（甚至不考虑分层导航中的参数），就可以知道您最终需要抓取多少个URL。

当然，每个商店都会有所不同，但是我想带回家的是，将站点爬到主要的FPC上是不切实际的。只要确保您的商店很快就能开始。

FPC有用的地方

FPC的优势发挥作用的地方是负载很重的商店-那里的流量确实很高，仅凭脚步下降就能自然而持续地填充缓存。

然后，FPC通过减少常见请求内容的基础架构开销来发挥作用-减少了对Magento后端的重复调用。

因此，我们发现FPC非常适合在流量非常高的情况下进行部署-不是减少页面加载时间-而是减少资源使用。

谁在乎，我还是想爬

好吧，那你有两个选择

  1. 从模板抓取（例如站点地图）
  2. 逐页提取链接并抓取每个链接

而且有很多实用程序可以同时完成这两个，这些都是我所知道的

  1. 魔法师
  2. HTTrack
  3. 纳奇
  4. 斯菲德
  5. 爬虫4j

使用法师测试

您可以轻松地使用Mage-Perftest搜寻您的商店，先下载它

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

然后，使用Magento站点地图定义抓取过程（您可以通过将任意URL制作为站点地图来进行自定义，前提是这些URL都包装在<loc></loc>标记中）。以下命令将从站点地图文件中读取所有URL，然后在1440分钟（1天）的时间内对URL进行爬网（仅PHP）。如果服务器超过20％CPU或平均负载为2，则爬网将暂时暂停。

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2

如果您在1天内抓取了1000个网址，则大约为。每86秒1个请求〜目标0.011 RPS

— 本·莱萨尼-索纳西
source
您的开头是非常正确的…… 页缓存不是提高性能的方法。我知道这个。您不知道我曾告诉客户多少次相同的事情。老实说，我以前从来没有在我们的网站上安装过搜寻器来启动FPC，而在客户端在管理员中启用它的情况下，它只使用过一次。我问的主要原因是因为我正在根据Nexcess白皮书中的一些研究来探索与此相关的想法。对于疯狂的高流量站点，在清晨刷新缓存后启动缓存可能很关键
— Davidalger 2013年
1
我尊重Nexcess，但是他们的白皮书非常注重缓存以提高性能，而不是确保环境已经有效并且代码干净，快速且高效。我们为客户提供清漆-但除非需要，否则请勿提倡使用。只有这样才能降低基础设施成本- 当约94％的非转换/结帐流量消耗CPU周期时。缓存可以提供良好的人工基准测试统计信息-但如果TTL太长（内容陈旧），则实际上没有任何意义-否则流量不足，无法启动。
— Ben Lessani-Sonassi
1
对于疯狂的高流量站点-我们有几个站点，并且尝试通过人工爬网保持高速缓存是没有意义的-自然流量就可以了。如果有的话，爬网只会删除客户原本会使用的资源。
— Ben Lessani-Sonassi
我希望在他们的白皮书中有所不同，白皮书专注于使用缓存来提高性能。他们显示了2 + 1集群可以实现多少吞吐量。他们甚至没有涉及页面加载时间，只有事务吞吐量。他们拥有的硬件已经尽可能地优化了……是的，我意识到TTL对缓存内容的影响。只是重申一下，我不希望在这里获得性能，我们已经拥有了。这将探索的方法是绕过由于清晨缓存刷新（即在正常流量恢复之前）而导致的吞吐量滞后/下降的方法。
— davidalger
1
那我很困惑。如果您的商店已经快了-但是在清除缓存时倒下了。a）不要在早上清除缓存，而是在前一天晚上清理缓存，然后让搜索爬网机器人（谷歌/必应等）为您做准备工作，或者b）获得正确的基础架构。如果您的商店依靠FPC /清漆来防止滞后/减速-听起来您像是在利刃上奔跑……
— Ben Lessani-Sonassi
0

这些天，我会全力以赴写一篇博客文章，但与此同时，我的小型缓存器也达到了顶峰wfpc。

测试性能

您可以测试Magento网站的性能

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

FPC变暖

然后，您可以预热FPC，它将打入sitemap.xml中的每个URL。

./wfpc -w http://mymagentosite.com/sitemap.xml

如果愿意，还可以在请求之间设置延迟，这是请求之间的延迟1秒。

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

测试模式仅随机命中10个URL，因此，在对FPC进行预热后，您可以运行测试模式以找出FPC带来的不同！

思想

就我个人而言，我认为取暖是有道理的...在一个只有40页的小型站点上，FPC将下载时间大约减少了一半。在一个拥有将近40,000个产品的大型站点上，使用Lesti_FPC和APCu作为后端，我为缓存使用了200MB以上的内存，坦率地说，在8GB的生产服务器上没有任何可用空间。

— 快速换档
source
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.