本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon S3 的效能設計模式
設計應用程式以從 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 是受管記憶體內快取。透過 ElastiCache，您可以佈建快取記憶體中物件的 Amazon EC2執行個體。此快取會導致GET延遲大幅降低，以及下載輸送量大幅增加。若要使用 ElastiCache，您可以將應用程式邏輯修改為使用熱門物件填入快取，並在向 Amazon S3 請求前檢查快取是否有熱門物件。如需使用 ElastiCache 改善 Amazon S3 GET效能的範例，請參閱部落格文章 Turbocharge Amazon S3 with Amazon ElastiCache for Redis。
AWS Elemental MediaStore 是專門為 Amazon S3 的影片工作流程和媒體交付而建置的 end-to-end快取和內容分發系統。 MediaStore 提供APIs專門用於影片的儲存體，建議用於效能敏感的影片工作負載。如需 的相關資訊 MediaStore，請參閱 AWS Elemental MediaStore 使用者指南 。
延遲敏感應用程式的逾時和重試
在某些情況下，應用程式會收到 Amazon S3 的回應，這表示有必要重試。Amazon S3 會將儲存貯體和物件名稱對應至相關聯的物件資料。如果應用程式產生高請求率 （通常每秒超過 5，000 個請求的持續率，變成少量物件），則可能會收到 HTTP 503 個慢速回應。如果發生這些錯誤，每個 AWS 錯誤都會使用指數退避SDK實作自動重試邏輯。如果您不使用 AWS SDK，您應該在收到 HTTP 503 錯誤時實作重試邏輯。如需退避技術的相關資訊，請參閱 AWS SDKs和 工具參考指南 中的重試行為。
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 資料連線的應用程式。例如， AWS Java 中的 Amazon S3 Transfer Manager 支援此功能SDK，而其他 AWS SDKs大多數也提供類似的建構。對於部分應用程式，您可以實現並行連線，方法為在不同的應用程式執行緒中或在不同的應用程式執行個體中並行啟動多個請求。採取的最佳方法取決於您的應用程式，以及您正在存取的物件結構。
您可以使用 AWS SDKs直接發出GET和PUT請求，而不是使用 中的傳輸管理 AWS SDK。此方法可讓您更直接地調整工作負載，同時仍可受益於 對重試SDK的支援，以及處理任何可能發生的 HTTP 503 回應。一般而言，當您從 Amazon S3 下載 區域中的大型物件至 Amazon EC2時，建議您同時請求物件的位元組範圍，精細度為 8–16 MB。為每個 85–90 提出一個並行請求MB/s of desired network throughput. To saturate a 10 Gb/s network interface card (NIC), you might use about 15 concurrent requests over separate connections. You can scale up the concurrent requests over more connections to saturate faster NICs, such as 25 Gb/s or 100 Gb/sNICs。
當您調整要同時發出的請求數時，測量效能很重要。我們建議從一次提出單一請求開始。測量要實現的網路頻寬，以及您的應用程式在處理資料時其他資源的使用情形。然後，您可以識別瓶頸資源 (亦即，具有最高用量的資源)，因此識別可能有用的請求數。例如，如果一次處理一個請求會導致 CPU 25% 的使用率，則表示最多可容納四個並行請求。測量是必要的操作，且隨著請求率的增加，確認資源用量是值得的。
如果您的應用程式使用 直接向 Amazon S3 REST 發出請求API，我們建議您使用HTTP連線集區，並針對一系列請求重複使用每個連線。避免每次請求連線設定，可消除對每個請求執行TCP慢啟動和安全通訊端層 （SSL） 交握的需求。如需有關使用 REST 的資訊API，請參閱 Amazon Simple Storage Service API參考 。
最後，請務必注意DNS並再次檢查請求是否分散到廣泛的 Amazon S3 IP 地址集區。DNS 透過大量的 IP 端點來查詢 Amazon S3 週期。但是快取解析程式或重複使用單一 IP 地址的應用程式碼不會受益於地址多樣性和隨之而來的負載平衡。網路公用程式工具，例如netstat命令列工具，可以顯示用於與 Amazon S3 通訊的 IP 地址，並提供要使用的DNS組態指南。如需這些指導方針的詳細資訊，請參閱在 Amazon S3 API參考 中提出請求。
使用 Amazon S3 Transfer Acceleration 來加速地理上不同的資料傳輸
使用 Amazon S3 Transfer Acceleration 設定快速安全的檔案傳輸在分散全球的客戶端與使用 Amazon S3 的區域應用程式之間， 可有效盡量降低或消除地理距離所引起的延遲。Transfer Acceleration 使用 中的全域分佈邊緣位置 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 速度比較工具
