# 高傳輸量的水平擴展與請求並行化 Amazon S3 是非常大的分散式系統。為了協助您善用其規模，建議您水平擴展對 Amazon S3 服務端點的並行請求。除了在 Amazon S3 內分發要求，這種擴展方法還有助於將負載分散至網路上的多個路徑。 對於高傳輸量傳輸，Amazon S3 建議使用對 GET 或 PUT 資料並行使用多個連線的應用程式。例如，AWS Java 開發套件中的 [Amazon S3 Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/examples-s3-transfermanager.html) 支援此作法，其他大多數 AWS 開發套件也提供類似的概念。對於部分應用程式，您可以實現並行連線，方法為在不同的應用程式執行緒中或在不同的應用程式執行個體中並行啟動多個請求。採取的最佳方法取決於您的應用程式，以及您正在存取的物件結構。 您可以使用 AWS 軟體開發套件，來直接發出 GET 和 PUT 請求，而非使用 AWS 軟體開發套件中管理傳輸的操作。此方法可讓您更直接調整工作負載，同時仍能受益於軟體開發套件支援重試，以及處理任何可能發生的 HTTP 503 回應。當您在區域內將大型物件從 Amazon S3 下載至 [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html) 時，我們通常建議您對物件的位元組範圍提出並行請求，精細程度為 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 S3 REST API 簡介](https://docs.aws.amazon.com/AmazonS3/latest/API/)。 最後，值得注意 DNS，並仔細檢查請求是否分散在廣泛的 Amazon S3 IP 地址集區。Amazon S3 的 DNS 查詢會在大量 IP 端點之中循環進行。但是快取解析程式或重複使用單一 IP 地址的應用程式碼不會受益於地址多樣性和隨之而來的負載平衡。網路公用程式工具 (例如 `netstat` 命令列工具) 可以顯示用來與 Amazon S3 通訊的 IP 地址，我們提供指導方針供 DNS 組態使用。如需這些準則的詳細資訊，請參閲[請求路由](https://docs.aws.amazon.com/AmazonS3/latest/dev/DNSConsiderations.html)。