Amazon CloudFront延迟 [英] Amazon CloudFront Latency

问题描述

我正在针对正在开发的Web应用程序试用AWS S3和CloudFront。

I am experimenting with AWS S3 and CloudFront for a web application that I am developing.

在应用程序中，我允许用户（使用AWS开发工具包）将文件上传到S3存储桶，并通过CloudFront CDN使其可用，但问题是文件已上传到S3存储桶中并准备就绪，需要大约一两分钟的时间才能在CloudFront CDN URL中使用，这是正常的吗？

In the app I'm letting users upload files to the S3 bucket (using the AWS SDK) and make it available via CloudFront CDN, but the issue is even when the files are uploaded and ready in the S3 bucket it takes about a minute or 2 to be available in the CloudFront CDN url, is this normal?

推荐答案

CloudFront尝试从原始服务器实时获取未缓存的内容。没有复制延迟或类似的问题，因为CloudFront是可穿透CDN。每个CloudFront边缘位置仅知道您站点的存在和配置；在收到您的内容请求之前，它不会知道您的内容。发生这种情况时，CloudFront边缘会从原始服务器获取请求的内容，并适当地对其进行缓存，以服务于后续请求。

CloudFront attempts to fetch uncached content from the origin server in real time. There is no "replication delay" or similar issue because CloudFront is a pull-through CDN. Each CloudFront edge location knows only about your site's existence and configuration; it doesn't know about your content until it receives requests for it. When that happens, the CloudFront edge fetches the requested content from the origin server, and caches it as appropriate, for serving subsequent requests.

此处发生的问题与有时称为负缓存的概念有关-缓存请求无效的事实-通常这样做是为了避免因可能无论如何都会失败的请求而影响正在缓存的内容的来源。

The issue that's occurring here is related to a concept sometimes called "negative caching" -- caching the fact that a request won't work -- which is typically done to avoid hammering the origin of whatever's being cached with requests that are likely to fail anyway.

默认情况下，当您的来源返回HTTP 4xx或5xx状态代码，CloudFront将这些错误响应缓存五分钟，然后将对对象的下一个请求提交到您的来源，以查看引起错误的问题是否已解决，并且所请求的对象现在可用

By default, when your origin returns an HTTP 4xx or 5xx status code, CloudFront caches these error responses for five minutes and then submits the next request for the object to your origin to see whether the problem that caused the error has been resolved and the requested object is now available.

^{—  http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html}

如果浏览器或其他工具尝试从该p下载文件关节CloudFront边缘上传到S3之前，S3将返回一个错误，并且CloudFront（在该边缘位置）将缓存该错误，并记住在接下来的5分钟内不要再尝试了。

If the browser, or anything else, tries to download the file from that particular CloudFront edge before the upload into S3 is complete, S3 will return an error, and CloudFront -- at that edge location -- will cache that error and remember, for the next 5 minutes, not to bother trying again.

不过，不必担心-该计时器是可配置的，因此，如果浏览器在后台进行并且在您的控制范围之外，您仍然应该可以对其进行修复。

Not to worry, though -- this timer is configurable, so if the browser is doing this under the hood and outside your control, you should still be able to fix it.

您可以为CloudFront的每个4xx和5xx状态码指定错误缓存持续时间-错误缓存最小TTL 缓存。有关过程，请参阅配置错误响应行为。

You can specify the error-caching duration—the Error Caching Minimum TTL—for each 4xx and 5xx status code that CloudFront caches. For a procedure, see Configuring Error Response Behavior.

^{— http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html}

---

要在控制台中进行配置：

• 查看分发配置时，单击错误页面标签。

对于每个要自定义计时的错误，请单击创建自定义错误响应。

For each error where you want to customize the timing, begin by clicking Create Custom Error Response.

从下拉列表中选择要修改的错误代码，例如 403 （禁止）或 404 （未找到）-您的存储桶配置确定S3为丢失的对象返回哪个代码，因此，如果不确定，请更改403，然后重复该过程，更改404。

Choose the error code you want to modify from the drop-down list, such as 403 (Forbidden) or 404 (Not Found) -- your bucket configuration determines which code S3 returns for missing objects, so if you aren't sure, change 403 then repeat the process and change 404.

将错误缓存最小TTL（秒） c设置为 0

保留自定义错误响应设置为否（如果设置为是，则此选项将对错误启用自定义响应内容，这不是您想要的。激活此选项不在范围内

Leave Customize Error Response set to No (If set to Yes, this option enables custom response content on errors, which is not what you want. Activating this option is outside the scope of this question.)

单击创建。这将带您回到上一个视图，在该视图中，您所看到的代码将显示 Error Caching Minimum TTL 。

Click Create. This takes you back to the previous view, where you'll see Error Caching Minimum TTL for the code you just defined.

对于要更改为默认行为（即保持300秒）的每个HTTP响应代码，重复这些步骤时间，如上所述）。

Repeat these steps for each HTTP response code you want to change from the default behavior (which is the 300 second hold time, discussed above).

完成所有所需的更改后，返回到CloudFront控制台主屏幕，其中列出了分布。等待分发状态从处理中更改为已部署（以前，这花了很长时间，但现在通常需要大约5分钟即可将更改推送到所有边缘）并进行测试。

When you've made all the changes you want, return to the main CloudFront console screen where the distributions are listed. Wait for the distribution state to change from In Progress to Deployed (formerly, this took quite some time but now requires typically about 5 minutes for the changes to be pushed out to all the edges) and test.

这篇关于Amazon CloudFront延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！