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.

在应用程序中，我让用户将文件上传到 S3 存储桶(使用 AWS 开发工具包)并通过 CloudFront CDN 使其可用，但问题是即使文件已上传并准备好在 S3 存储桶中也需要大约CloudFront CDN 网址中还有一两分钟可用，这正常吗?

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}

如果浏览器或其他任何东西在上传到 S3 完成之前尝试从该特定 CloudFront 边缘下载文件，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}

<小时>

要在控制台中进行配置:

• 查看分发配置时，单击Error Pages 选项卡.

对于您想要自定义时间的每个错误，首先单击创建自定义错误响应.

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(秒)设置为0

Leave Customize Error Response 设置为 No(如果设置为 Yes，此选项启用错误的自定义响应内容，这不是您想要的.激活此选项不在此问题的范围内.)

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 控制台屏幕，其中列出了分配.等待分发状态从 In Progress 更改为 Deployed(以前，这需要相当长的时间，但现在通常需要大约 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屋！