本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon S3 的效能設計模式
設計應用程式以從 Amazon S3 上傳和擷取物件時，請採用我們的最佳實務設計模式，讓您的應用程式達到最佳效能。我們也提供效能指導方針，供您在規劃應用程式架構時考量。
若要最佳化效能，您可以使用下列設計模式。
對經常存取的內容使用快取
許多將資料存放在 Amazon S3 的應用程式會提供資料「工作集」，供使用者重複請求。如果工作負載針對一組通用物件傳送重複的 GET 請求，您可以使用 Amazon CloudFront、Amazon 等快取 ElastiCache，或AWS Elemental MediaStore將效能最佳化。成功採用快取可以產生低延遲和高資料傳輸率。使用快取的應用程式傳送至 Amazon S3 的直接請求也較少，有助於減少請求成本。
Amazon CloudFront 是一種快速內容交付網路 (CDN)，可透明地從 Amazon S3 快取資料，並在一組分散各地的存在點 (PoPs) 中快取資料。當物件可從多個區域或透過網際網路存取時，可 CloudFront 讓資料快取靠近存取物件的使用者。這樣能夠高效能傳遞熱門的 Amazon S3 內容。如需相關資訊 CloudFront，請參閱 Amazon CloudFront 開發人員指南。
Amazon ElastiCache 是一個受管的，內存緩存。您可以使用佈建 Amazon EC2 執行個體 ElastiCache，以快取記憶體中的物件。此快取會導致 GET 延遲數量級減少，以及下載傳輸量顯著增加。若要使用 ElastiCache，您可以修改應用程式邏輯，以便在快取中填入熱物件，並在從 Amazon S3 請求這些物件之前檢查快取是否有熱物件。如需用 ElastiCache 來改善 Amazon S3 GET 效能的範例，請參閱部落格文章使用 Amazon ElastiCache 為 Redis 渦輪增壓 Amazon S3
AWS Elemental MediaStore 是專為 Amazon S3 視訊工作流程和媒體交付而建置的快取和內容分發系統。 MediaStore 提供專門用於視訊的 end-to-end 儲存 API，建議用於對效能敏感的視訊工作負載使用。若要取得有關資訊 MediaStore，請參閱《AWS Elemental MediaStore 使用指南》。
適用於對延遲敏感之應用程式的逾時和重試
在某些情況下，應用程式會收到 Amazon S3 的回應，這表示有必要重試。Amazon S3 會將儲存貯體和物件名稱對應至相關聯的物件資料。如果應用程式產生高請求率 (通常對少數物件維持每秒超過 5,000 個請求的速率)，則它可能會收到 HTTP 503 slowdown 回應。如果發生這些錯誤，每個 AWS 開發套件會使用指數退避來實作自動重試邏輯。如果您未使用 AWS 開發套件，則應該在收到 HTTP 503 錯誤時實作重試邏輯。如需有關退期技術的資訊，請參閱中的錯誤重試和指數輪詢。 AWSAmazon Web Services 一般參考
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 開發人員指南中的限制，以取得您使用案例支援的請求率的相關資訊。
高傳輸量的水平擴展和請求並行化
Amazon S3 是非常大的分散式系統。為了協助您善用其規模，建議您水平擴展對 Amazon S3 服務端點的並行請求。除了在 Amazon S3 內分發要求，這種擴展方法還有助於將負載分散至網路上的多個路徑。
對於高傳輸量傳輸，Amazon S3 建議使用對 GET 或 PUT 資料並行使用多個連線的應用程式。例如，Amazon S3 傳輸管理器在 AWS Java 開發套件中支援此功能，而大多數其他開 AWS 發套件都提供類似的建構。對於部分應用程式，您可以實現並行連線，方法為在不同的應用程式執行緒中或在不同的應用程式執行個體中並行啟動多個請求。採取的最佳方法取決於您的應用程式，以及您正在存取的物件結構。
您可以使用 AWS SDK 直接發出 GET 和 PUT 請求，而不是採用 AWS SDK 中的傳輸管理。此方法可讓您更直接調整工作負載，同時仍能受益於軟體開發套件支援重試，以及處理任何可能發生的 HTTP 503 回應。當您在區域內將大型物件從 Amazon S3 下載至 Amazon EC2 時，我們通常建議您對物件的位元組範圍提出並行請求，精細程度為 8–16 MB。針對所需網路輸送量的每個 85–90 MB/s，提出一個並行請求。若要使 10 Gb/s 網路界面卡 (NIC) 飽和，您可以透過個別連線使用大約 15 個並行請求。您可以透過更多連線來擴增並行請求，使更快的 NIC 飽和，例如 25 Gb/s 或 100 Gb/s NIC。
當您調整要同時發出的請求數時，測量效能很重要。我們建議從一次提出單一請求開始。測量要實現的網路頻寬，以及您的應用程式在處理資料時其他資源的使用情形。然後，您可以識別瓶頸資源 (亦即，具有最高用量的資源)，因此識別可能有用的請求數。例如，如果一次處理一個請求導致使用 25% CPU，則其建議最多只能容納四個並行請求。測量是必要的操作，且隨著請求率的增加，確認資源用量是值得的。
如果您的應用程式使用 REST API 直接向 Amazon S3 發出請求，我們建議您使用 HTTP 連線集區，並針對一系列請求重複使用每個連線。避免每個請求的連線設定可移除在每個請求上執行 TCP 緩慢啟動和 Secure Sockets Layer (SSL) 交握的需求。如需有關使用 REST API 的詳細資訊，請參閱 Amazon Simple Storage Service API 參考。
最後，值得注意 DNS，並仔細檢查請求是否分散在廣泛的 Amazon S3 IP 地址集區。Amazon S3 的 DNS 查詢會在大量 IP 端點之中循環進行。但是快取解析程式或重複使用單一 IP 地址的應用程式碼不會受益於地址多樣性和隨之而來的負載平衡。網路公用程式工具 (例如 netstat 命令列工具) 可以顯示用來與 Amazon S3 通訊的 IP 地址，我們提供指導方針供 DNS 組態使用。如需這些指導方針的詳細資訊，請參閱「提出要求」。
使用 Amazon S3 Transfer Acceleration 加速異地資料傳輸
使用 Amazon S3 Transfer Acceleration 設定快速安全的檔案傳輸在分散全球的客戶端與使用 Amazon S3 的區域應用程式之間， 可有效盡量降低或消除地理距離所引起的延遲。傳輸加速會使用中的全域分散式邊緣位置 CloudFront 進行資料傳輸。邊 AWS 緣網路在 50 多個位置有存在點。如今，它可用於透過分發內容， CloudFront 並為對 Amazon Route 53 進行的 DNS 查詢提供快速回應。
邊緣網路也有助於加速進出 Amazon S3 的資料傳輸。它非常適合於各大洲之間傳輸資料的應用程式、具有快速網際網路連線的應用程式、使用大型物件的應用程式，或具有許多內容要上傳的應用程式。當資料到達節點時，資料會經由最佳化的網路路徑而路由至 Amazon S3。一般而言，離 Amazon S3 區域越遠，使用 Transfer Acceleration 改善速度越明顯。
您可以在新的或現有的儲存貯體上設定 Transfer Acceleration。您可以使用單獨的 Amazon S3 Transfer Acceleration 端點來使用 AWS 節點。測試 Transfer Acceleration 是否可提升用戶端請求效能的最好方式，就是使用 Amazon S3 Transfer Acceleration 速度比較工具
