图像上的 S3 cloudfront 到期 - 性能非常慢答案

【问题标题】：S3 cloudfront expiry on images - performance very slow图像上的 S3 cloudfront 到期 - 性能非常慢
【发布时间】：2014-05-19 12:02:03
【问题描述】：

我最近开始在云端 CDN 而不是 S3 上提供我的网站图片，我认为它会更快。它不是。事实上，它要慢得多。经过大量调查后，我被暗示设置图像对象的到期日期是关键，因为 Cloudfront 将知道将缓存的静态内容保留多长时间。说得通。但是 AWS 对此的记录很差，我不知道如何更改到期日期。人们说“你可以在 aws 控制台上更改它”请展示我有多愚蠢，因为我看不到这一点。已经在这几个小时了。不用说，我对在这方面摸索感到非常沮丧。无论如何，任何尽可能小的提示都会很棒。我喜欢 AWS，也喜欢 Cloudfront 所承诺的，但目前看来并非如此。

编辑其他细节：每个答案添加了到期日期标题。就我而言，我没有标题。我的假设是，我缓慢的 Cloudfront 性能服务图像与标题中没有过期有关。设置了如屏幕截图所示的到期日期并在答案中进行了描述，我发现性能没有明显差异（从没有标题到仅添加到期日期）。我的网站平均需要 7 秒来加载 10 个核心图像（每个

【问题讨论】：

我发现 CloudFront 的性能也变差了 - 一年后...您有没有得到解决方案，或者您只是切换到 MaxCDN？

标签： amazon-web-services amazon-s3 amazon-cloudfront

【解决方案1】：

在将文件上传到 S3 时，您需要在元数据中进行设置。 This article 描述了如何实现这一目标。

到期日期的格式是 RFC1123 日期，格式如下：

Expires: Thu, 01 Dec 1994 16:00:00 GMT

将此设置为遥远的未来日期将使 CloudFront 等缓存能够长时间保存文件，并且在这种情况下加快交付速度，因为单个边缘位置（世界各地的服务器为 CloudFront 提供内容）已经拥有数据，不需要一次又一次地获取它。

即使有一个遥远的未来到期标头，对象的第一个请求也会很慢，因为边缘位置必须先获取一次对象，然后才能从缓存中提供它。

或者您可以省略 Expires 标头并改用 Cache-Control。 CloudFront 也会理解这一点，并且您在到期时会更加灵活。在这种情况下，例如，您可以声明该对象应该从第一次请求边缘位置到该对象的一天：

Cache-Control: public, max-age=86400

在这种情况下，时间使用秒而不是固定日期给出。

【讨论】：

这篇文章一点帮助都没有。
好的，那么使对象过期会提高性能吗？什么是最佳时间？我应该如何格式化日期？这些是由 cloudfront 提供的网站上的静态图像。
如果您确定您永远不会再次更改图像，您可以将过期时间设置为 2100 甚至更晚。日期示例如下：Expires: Thu, 01 Dec 1994 16:00:00 GMT
我对那篇文章充满希望，但没有骰子。我输入了您希望图像从缓存中过期的值/日期（即，2021 年 4 月 23 日星期五 10:18:36 GMT）。事实上，我在每个示例中都使用了相同的日期。然后点击保存。没什么见截图screencast.com/t/ce8f7w3a
天啊，如果它真的改变了怎么办？我的网站在 Cloudfront 上加载了 1999 等图像。我在这里做正确的事吗？为什么点击保存后它没有显示到期日期？谢谢你。但这太令人沮丧了。

【解决方案2】：

虽然设置 Cache-Control 或 Expires 标头会提高对象的缓存能力，但不会提高 60k/秒的下载速度。这需要 AWS 的一些帮助。因此，我建议将一些示例响应标头、跟踪路由和解析器信息发布到AWS CloudFront Forums。

【讨论】：