AWS CloudFront是否应“增加”不经常访问的文件的加载时间?


9

我是CDN的新手,正在尝试CloudFront。我已经完成所有设置,并且看起来一切正常。我可以在页面上创建静态图像,并通过我的CloudFront发行版访问它。我正在使用自定义来源(即不是s3存储桶)。

我担心从性能的角度来看可能会更糟。我有一个测试页,可以加载和不加载CDN的相同20张左右的图像。在Firebug的网络面板中,我第一次加载此页面时,直接从源服务器加载的图像的速度要快得多。在随后的页面加载中,CDN的好处显而易见-在3-5次刷新后,CDN的性能要优于原始服务器。

因此,我可以看到在我们网站上一个经常被访问的受欢迎页面上,这将是一个好处。而且我应该会受益匪浅,因为我在西雅图(在亚马逊附近)并且我的服务器在CA中。

关键是,如果我离开页面几分钟然后重新加载,事情又回到了第一点,CloudFront比原始服务器差。这是预期的吗?事情会这么快地退出CDN“缓存”吗?

我的设置中是否有可能损害性能?还是CDN只会对目前平均每隔几秒钟访问一次的内容产生积极影响?

(交叉从AWS论坛发布,因为我永远被SO的周转时间宠坏了)

更新:

如果您对CloudFront性能有疑问,下面有两个不错的答案值得一看。最近,我发现没有提及针对我的具体问题的一种解释。我在第5分钟离开了TTL作为监督。由于我也使用自定义来源,因此需要进行一次往返于权威名称服务器的往返操作,以将其解析为实际的Amazon CloudFront域。现在,TTL设置已恢复到12小时,似乎长负载的情况很少出现了。


是的,CloudFront可能比直接连接到快速服务器要慢,这是因为CloudFront是那里最慢的CDN之一,这是由于Amazon通过多层DNS解析等方式实现的CDN的原因。并确定是否适合您-使用webpagetest.org进行测试。
Jesper M

Answers:


5

Cloudfront在答复中设置标题,例如答复中的“ X-Cache:从Cloudfront命中”。如果您的文件不在您定向到的节点的缓存中,则大概会说“ Miss”。

您的文件可能不够流行,因此即使没有经过24小时,它们也会从CloudFront的缓存中被更多流行的内容弹出。IO过载或特定CloudFront节点内部的其他情况也可能使访问变慢。与Akamai或LimeLight相比,Cloudfront非常便宜。最差的性能和有保证的服务水平是使用价格昂贵的播放器的两个原因。

我将进行测试,将仅一个流行的文件放入生产环境中的Cloudfront中,然后使用定期测试来查看CloudFront是否指示命中(还记录总交易时间)。


我用另一个可能的性能问题解释了这个问题,这是我看到的性能问题的另一种可能的解释,即我将TTL设置留在了5分钟的低设置,但是当切换回12小时时,我认为我没有看到这些偶尔出现性能问题。
格雷格,

7

有可能的。但是,CDN的目的之一是可伸缩性。如果您一次抛出100次访问或一次访问一百万次,则CDN可以执行相同的操作。

就您的设置而言,您提供的信息对我一无所知,但我认为以上几点才使CDN如此有价值。如果您要创建的网站流量不多,那么最好不要使用CDN。但是,如果您获得大量流量,则CDN将减轻Web服务器的负担,因为您正在将媒体服务传递给另一台服务器。最后一点,一个好的CDN(和Amazon的CDN)将利用其广泛的网络从最靠近请求者的位置为您的内容提供服务。在许多情况下,它们可以从请求者的ISP提供内容,这意味着非常快的加载时间。

希望能有所帮助。


谢谢杰西-非常有帮助。关于缩放的观点是正确的。而且我们有足够的流量来使它产生很大的变化。我仍然很想知道缓存策略。我发现了大量有关如何建立CDN的信息,而关于CDN的特征却很少。例如,我想知道是否应该从CDN中排除很少访问的旧内容。
格雷格

格雷格-除了财务上的原因外,我没有看到排除内容的理由。但是,您可以控制Amazon中对象的缓存标头。:您可能会尝试寻找这个stackoverflow.com/questions/269840/...
杰西束

这样一来,您可以像指定任何普通网站的媒体一样指定远期到期标头。
Jesse Bunch

再次感谢。该缓存控制链接与我的情况无关,因为我使用的是自定义原始服务器,而不是s3。但是原则适用,而且我确实设置了远期的过期标头。顺便说一句,亚马逊的文档确实说内容会在缓存中保留24小时,但是我的实验表明有所不同。
格雷格

1

我误会了吗?在边缘位置从S3重新加载事物之前,高速缓存控件是否管理边缘事物的生存时间?因此,无论您使用S3还是您自己的血统,它们是否与您的情况有关?没有?

亚马逊FAQ说:“亚马逊的CloudFront的会问:能维持多久我的档案在边缘位置默认情况下,如果没有高速缓存控制头设置,每一个边缘位置检查文件的更新版本时,它接收到一个请求超过在上次时间之后的24小时内,它检查了源文件是否已更改,这称为“有效期限”。您可以通过在源中的文件上设置缓存控制标头来设置此有效期短至1小时,也可以根据需要设置任意长的时间Amazon CloudFront使用这些缓存控制标头来确定需要多长时间检查一次该文件的更新版本的来源。如果您的文件不经常更改,则最佳做法是设置较长的有效期限并实施版本控制系统来管理文件的更新。”

[我认为最后一句话的意思是“如果将它设置为50年然后要更改文件,则很不幸”。]

使用CDN托管静态内容不是主要目的吗?如果是这样,使用比一天更长的TTL是否有帮助?对于几乎所有内容(所有图像和CSS),我都使用Cache-Control =“ max-age = 604800,public,必须重新验证”(即1周)。根据我的经验,如果我将新版本上载到S3,则文件肯定要花一周的时间进行更改。

希望这可以帮助。[BTW:从更笼统的角度来看,我也想知道CDN是否能帮助您达到预期的效果。我将把我的整个站点(包括CDN)移到超快速的专用服务器上,并进行一些测试以找出答案。]


您是正确的,缓存控制会影响内容在边缘保留多长时间。TTL是一个单独的问题。TTL控制分配给域名的IP地址的缓存。因此,无论静态文件是否缓存在边缘,服务器第一次看到文件的URL时都必须查找该域的IP地址。使用1天的TTL,附近的服务器很可能在其DNS缓存中包含此信息。TTL为5分钟的可能性很小,因此需要完整往返我的原始服务器(不是用于文件,而是用于解析URL)
Greg

好的,谢谢。我在混淆DNS TTL和缓存控制:)
Chris W

1

使用CDN的原因是您是否期望

  • 静态内容-很少或受控的更新
  • 环游世界
  • 经常访问

根据您的情况,很少会访问我们的网站,但是我们有一个监控服务设置,可以请求世界各地的我们的网站。因此,它使CDN缓存保持温暖。我也想分享一下我们的案例,它是一个简单的案例,展示了CDN的功能。

此外,我们预计每月的费用为2.2美元,而Godaddy服务器的费用为7美元(无法应付激增的费用)

平均页面加载时间

平均页面加载时间分布

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.