# 延迟敏感型应用程序的超时和重试
<a name="timeouts-and-retries-for-latency-sensitive-applications"></a>

在某些情况下，应用程序会收到来自 Amazon S3 的响应，指示需要重试。Amazon S3 将存储桶和对象名称映射到与其关联的对象数据。如果应用程序生成高的请求率（通常针对少量对象持续超过每秒 5,000 个请求的速率），则它可能会收到 HTTP 503 *速度下降* 响应。如果出现这些错误，每个 AWS 开发工具包都会使用指数退避来实现自动重试逻辑。如果您不使用 AWS 开发工具包，则应在收到 HTTP 503 错误时实施重试逻辑。有关退避技术的信息，请参阅《Amazon Web Services 一般参考》**中的 [AWS 中的错误重试和指数退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)。

Amazon S3 自动扩展以应对持续的新请求速率，同时动态地优化性能。尽管 Amazon S3 在内部针对新的请求速率进行优化，但您将临时收到 HTTP 503 请求响应，直至优化完成。当 Amazon S3 在内部针对新的请求速率优化性能后，通常无需重试就能正常应对所有请求。

对于延迟密集型应用程序，Amazon S3 建议跟踪和主动重试较慢的操作。当重试请求时，我们建议您使用到 Amazon S3 的新连接并执行全新 DNS 查找。

当您发出大型可变大小的请求（例如，超过 128 MB）时，我们建议跟踪所实现的吞吐量并重试最慢 5% 的请求。当您发出较小的请求（例如，小于 512 KB）时，其中，延迟时间中值通常处于数十毫秒的范围内，好的指导原则是在 2 秒后重试 GET 或 PUT 操作。如果需要更多重试，则最佳实践是退避。例如，我们建议您在 2 秒后发出一次重试，然后 4 秒后再发出一次重试。

如果应用程序对 Amazon S3 发出固定大小的请求，则应预期对于其中每个请求获得更一致的响应时间。在这种情况下，一个简单的策略是确定最慢的 1% 的请求并重试这些请求。甚至一次重试也会频繁、有效地减少延迟。

如果您使用 AWS Key Management Service (AWS KMS) 进行服务器端加密，请参阅《AWS Key Management Service 开发人员指南》**中的[配额](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html)，以获取有关使用案例支持的请求速率的信息。