本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon S3 的效能準則
<a name="optimizing-performance-guidelines"></a>

建置從 Amazon S3 上傳和擷取物件的應用程式時，請依照我們的最佳實務指導方針來最佳化效能。我們還提供更詳細的[Amazon S3 的效能設計模式 ](optimizing-performance-design-patterns.md)。

為了讓您在 Amazon S3 上的應用程式獲得最佳效能，建議採用下列指導方針。

**Topics**
+ [

## 測量效能
](#optimizing-performance-guidelines-measure)
+ [

## 水平擴展儲存體連線
](#optimizing-performance-guidelines-scale)
+ [

## 使用位元組範圍擷取
](#optimizing-performance-guidelines-get-range)
+ [

## 對延遲敏感的應用程式重試請求
](#optimizing-performance-guidelines-retry)
+ [

## 在相同的 中結合 Amazon S3 （儲存） 和 Amazon EC2 （運算） AWS 區域
](#optimizing-performance-guidelines-combine)
+ [

## 使用 Amazon S3 Transfer Acceleration 將距離造成的延遲降到最低
](#optimizing-performance-guidelines-acceleration)
+ [

## 使用最新版本的 AWS SDKs
](#optimizing-performance-guidelines-sdk)

## 測量效能
<a name="optimizing-performance-guidelines-measure"></a>

最佳化效能時，請查看網路傳輸量、CPU 和 DRAM 要求。根據這些不同資源的混合需求，可能值得評估不同的 [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html) 執行個體類型。如需詳細資訊，請參閱《Amazon EC2 使用者指南》**中的[執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。

測量效能時，使用 HTTP 分析工具來查看 DNS 查閱時間、延遲和資料傳輸速度也很有幫助。

 若要了解效能需求並最佳化您應用程式的效能，您也可以監控收到的 503 錯誤回應。監控某些效能指標可能會產生額外費用。如需詳細資訊，請參閱 [Simple Storage Service (Amazon S3) 定價](https://aws.amazon.com/s3/pricing/)。

### 監控 503 (減慢) 狀態錯誤回應的數目
<a name="optimizing-performance-guidelines-measure-503"></a>

 若要監控您取得的 503 狀態錯誤回應數目，您可以使用下列其中一個選項：
+ 使用 Amazon S3 的 Amazon CloudWatch 請求指標。CloudWatch 請求指標包含 5xx 狀態回應的指標。如需 CloudWatch 請求指標的詳細資訊，請參閱 [使用 Amazon CloudWatch 監控指標](cloudwatch-monitoring.md)。
+ 使用 Amazon S3 Storage Lens 的進階指標區段中提供的 503 (服務無法使用) 錯誤計數。如需詳細資訊，請參閱[使用 S3 Storage Lens 指標來改善效能](storage-lens-detailed-status-code.md)。
+ 使用 Amazon S3 伺服器存取記錄 使用伺服器存取記錄，您可以篩選並檢閱接收 503 (內部錯誤) 回應的所有請求。您也可以使用 Amazon Athena 來剖析日誌。如需伺服器存取記錄日誌的詳細資訊，請參閱「[使用伺服器存取記錄記錄要求](ServerLogs.md)」。

 透過監控 HTTP 503 狀態錯誤碼的數量，您通常可以獲得寶貴的洞見，了解哪些字首、金鑰或儲存貯體得到最多的限流請求。

## 水平擴展儲存體連線
<a name="optimizing-performance-guidelines-scale"></a>

跨許多連線傳播請求是常用的設計模式，藉此水平擴展效能。建置高效能應用程式時，請將 Amazon S3 視為一個非常大的分散式系統，而不是像傳統儲存伺服器那樣的單一網路端點。您可以向 Amazon S3 發出多個並行請求，以達到最佳效能。將這些請求分散到不同的連線，以從 Amazon S3 獲得最大可存取的頻寬。Amazon S3 對儲存貯體的連線數沒有任何限制。

## 使用位元組範圍擷取
<a name="optimizing-performance-guidelines-get-range"></a>

您可以在 [GET 物件](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html)請求中使用 `Range` HTTP 標頭，以從物件中擷取位元組範圍，僅傳輸指定的部分。您可以對 Amazon S3 使用並行連線，從同一物件內擷取不同的位元組範圍。與單一整個物件請求相比，這可協助您實現更高的彙總傳輸量。擷取大型物件的更小範圍也可讓您的應用程式在請求中斷時改善重試時間。如需詳細資訊，請參閱[下載物件](download-objects.md)。

如果物件是使用多部件上傳的 PUT，則良好實務為以相同部件大小 (或至少與部件界限一致) GET 它們，以取得最佳效能。GET 請求可以直接處理個別組件；例如，`GET ?partNumber=N.`

## 對延遲敏感的應用程式重試請求
<a name="optimizing-performance-guidelines-retry"></a>

積極的逾時和重試可協助推動一致的延遲。由於 Amazon S3 的範圍很大，如果第一個請求很慢，則重試的請求可能會採取不同路徑且很快成功。 AWS SDKs 具有可設定的逾時和重試值，您可以根據特定應用程式的公差進行調整。

## 在相同的 中結合 Amazon S3 （儲存） 和 Amazon EC2 （運算） AWS 區域
<a name="optimizing-performance-guidelines-combine"></a>

雖然 S3 儲存貯體名稱是全域唯一，但每個儲存貯體都存放在您建立儲存貯體時選取的區域中。若要進一步了解儲存貯體命名準則，請參閱[儲存貯體概觀](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)和[儲存貯體命名規則](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)。為了最佳化效能，我們建議您 AWS 區域 盡可能從相同 中的 Amazon EC2 執行個體存取儲存貯體。這可協助減少網路延遲和資料傳輸成本。

如需資料傳輸成本的詳細資訊，請參閱 [Amazon S3 定價](https://aws.amazon.com/s3/pricing/)。

## 使用 Amazon S3 Transfer Acceleration 將距離造成的延遲降到最低
<a name="optimizing-performance-guidelines-acceleration"></a>

[使用 Amazon S3 Transfer Acceleration 設定快速安全的檔案傳輸](transfer-acceleration.md) 可讓用戶端與 S3 儲存貯體之間長地理距離的檔案傳輸變得迅速、簡單又安全。Transfer Acceleration 善用 [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) 中遍佈全球的節點。資料到達節點時會經由最佳化的網路路徑而路由至 Amazon S3。Transfer Acceleration 非常適合在各大洲定期傳輸數 GB 到數 TB 的資料。也有助於從世界各地上傳至集中型儲存貯體的用戶端。

您可以使用 [Amazon S3 Transfer Acceleration 速度比較工具](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html)，比較各 Amazon S3 區域的加速和非加速上傳速度。速度比較工具在使用和不使用 Amazon S3 Transfer Acceleration 的情況下，透過分段上傳，將檔案從您的瀏覽器傳送至各個 Amazon S3 區域。

## 使用最新版本的 AWS SDKs
<a name="optimizing-performance-guidelines-sdk"></a>

 AWS SDKs 為許多最佳化 Amazon S3 效能的建議準則提供內建支援。這些開發套件提供更簡單的 API 以方便從應用程式內善用 Amazon S3，並定期更新來遵循最新的最佳實務。例如，軟體開發套件包括在發生 HTTP 503 錯誤時自動重試請求的邏輯，並投資於程式碼以回應並適應慢速連線。

這些開發套件也提供 [Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3-transfermanager.html)，在適當情況下會使用位元組範圍請求，以自動水平擴展連線，達到每秒數千個請求。請務必使用最新版本的 AWS SDKs來取得最新的效能最佳化功能。

使用 HTTP REST API 請求時，您也可以最佳化效能。使用 REST API 時，您應該遵循屬於軟體開發套件的相同最佳實務。允許逾時和重試慢速請求，並有多個連線允許平行擷取物件資料。如需有關使用 REST API 的詳細資訊，請參閱 [Amazon Simple Storage Service API 參考](https://docs.aws.amazon.com/AmazonS3/latest/API/)。