# 適用於對延遲敏感之應用程式的逾時和重試
<a name="timeouts-and-retries-for-latency-sensitive-applications"></a>

在某些情況下，應用程式會收到 Amazon S3 的回應，這表示有必要重試。Amazon S3 會將儲存貯體和物件名稱對應至相關聯的物件資料。若應用程式產生高請求率 (通常對少數物件維持每秒超過 5,000 個請求的速率)，則其可能會收到 HTTP 503 *slowdown* 回應。如果發生這些錯誤，每個 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)，以取得使用案例所支援之請求率的相關資訊。