的效能最佳實務 適用於 .NET 的 AWS SDK

建立用戶端、處理回應和設定應用程式的方式，會對輸送量、延遲和記憶體使用量產生很大的影響。本主題說明可協助應用程式有效且可靠地執行的用量和組態模式。這些模式在高負載或資源受限的環境中最為重要，例如容器和無伺服器函數。遵循這些實務可以改善效能，並防止常見問題，例如回應緩慢、懸置和高記憶體使用量。

最具影響力的做法如下：

開始之前，請確定您已設定環境並設定專案。

重複使用單一、長期的服務用戶端

AmazonS3Client 和 AmazonDynamoDBClient 等服務用戶端具有執行緒安全性，建構成本相對較高，且壽命較長。建構用戶端可解析區域和端點資訊，並建立基礎 HTTP 基礎設施。為每個服務建立一個用戶端，並在應用程式的生命週期內重複使用它。如果您呼叫多個區域，請為每個區域建立單獨的用戶端。

在使用相依性插入的應用程式中，將用戶端註冊為單一用戶端。AWSSDK.Extensions.NETCore.Setup NuGet 套件的AddAWSService延伸方法會將用戶端註冊為預設的 生命週期ServiceLifetime.Singleton。用戶端會在第一次請求時建立，並在程序的生命週期內重複使用相同的執行個體。如需使用相依性注入註冊 AWS 服務以及從組態讀取選項的詳細資訊，請參閱 AWSSDK.Extensions.NETCore.Setup 和 IConfiguration。

您也可以手動將用戶端註冊為單一用戶端。

builder.Services.AddSingleton<IAmazonS3>(_ => new AmazonS3Client());

重複使用用戶端並不表示您應該停止處理每個操作的回應。在應用程式的生命週期內重複使用用戶端，但繼續處置個別操作傳回的回應和串流，如 中所述處置回應和串流。

處置回應和串流以釋出連線

有些 SDK 回應物件具有即時網路串流。最常見的範例是 GetObjectResponse，它會透過其ResponseStream屬性實作IDisposable和公開物件的內容。回應會保留開放的 HTTP 連線，直到串流完全讀取或回應遭到處置為止。如果您洩漏這些回應 （例如，透過在迴圈GetObject中呼叫而不捨棄每個結果），開啟的連線會累積到連線集區耗盡為止，以及下一個呼叫區塊。這是「隨機」或停止在 Nth 物件上的下載報告背後的原因。

一律將串流回應包裝在using陳述式中，並立即讀取或複製其串流。

using Amazon.S3;
using Amazon.S3.Model;

// s3Client is a reused, long-lived client.
var request = new GetObjectRequest { BucketName = bucketName, Key = key };

using var response = await s3Client.GetObjectAsync(request);
await response.WriteResponseStreamToFileAsync(filePath, append: false, CancellationToken.None);

處置回應並處置其ResponseStream相當；其中一個會關閉基礎網路串流，並傳回與集區的連線。

var metadata = await s3Client.GetObjectMetadataAsync(bucketName, key);
Console.WriteLine($"Size: {metadata.ContentLength} bytes");

正確使用非同步/等待

在現代 .NET 上， 中的服務操作 適用於 .NET 的 AWS SDK 是非同步的，並傳回 Task。在 .NET Framework 上，同步方法也存在，但建議使用更好的非同步呼叫擴展。使用 操作await，並將程式碼async的每一層傳播到進入點。如需使用 SDK 進行非同步程式設計的詳細資訊，請參閱 非同步程式設計。

下列方法會在非同步呼叫上封鎖 ，並可能使執行緒集區死結或挹注。

// Anti-pattern: do not do this.
public GetObjectResponse Get(GetObjectRequest request)
{
    return s3Client.GetObjectAsync(request).Result;
}

請改為進行 方法async和 await 呼叫。

public async Task<GetObjectResponse> GetAsync(GetObjectRequest request)
{
    return await s3Client.GetObjectAsync(request);
}

非同步程式碼的其他建議：

設定 AWS Lambda 和 Amazon ECS 的 .NET 垃圾回收

當容器出現「記憶體洩漏」時，.NET 垃圾收集器 (GC) 可能會保留回收的記憶體以供重複使用。因此，即使受管堆積未增長，程序記憶體也會顯示高且穩定。此外，GC 不會自動偵測容器的記憶體限制 （其 cgroup 限制）。在受限的環境中，堆積可能會增加到主機的記憶體，而不是容器的限制。這可能會導致 OutOfMemoryException或容器終止。

為了協助 GC 在受限的環境中正常運作：

如需這些設定的詳細資訊，請參閱 https：// 上的垃圾回收執行時間組態選項。 learn.microsoft.com 如需 AWS 運算的特定指引，請參閱 AWS 開發人員工具部落格文章為 Amazon ECS 和 設定 .NET 垃圾回收 AWS Lambda。

管理 HTTP 連線和連線限制

在高輸送量下，兩個與連線相關的問題很常見。第一個是開啟太多短期連線。這會耗盡暫時性連接埠、在 中保留通訊端TIME_WAIT，並新增 TCP 和 TLS 交握延遲。第二個連線數量太少，造成平行處理瓶頸。重複使用單一長期用戶端 （請參閱重複使用服務用戶端) 是正常運作連線集區的基礎，因為集區取決於要重複使用的用戶端。

若要調整每個端點的並行連線數，請在用戶端組態上設定 MaxConnectionsPerServer 屬性。當此屬性為 null（預設值） 時，會套用基礎HttpClientHandler預設值，這實際上在現代 .NET 上不受限制。只有當對相同端點的許多並行請求在連線上遇到瓶頸時，才會引發此錯誤。良好的起點是每個端點預期的並行請求尖峰數量。將其設定為遠高於工作負載需要浪費通訊端，而不會改善輸送量。

using Amazon.S3;

var config = new AmazonS3Config
{
    MaxConnectionsPerServer = 50
};

var s3Client = new AmazonS3Client(config);

如果您已使用相依性插入，請透過 設定您的用戶端AWSSDK.Extensions.NETCore.Setup。當您使用 DI 或註冊數個服務用戶端時，建議使用此方法。它集中了組態，並使用戶端易於注入和測試。您可以從應用程式的組態設定組態值，而不是在程式碼中設定。如需詳細資訊，請參閱AWSSDK.Extensions.NETCore.Setup 和 IConfiguration。

最後，將自己的平行處理綁定，這樣您就不會啟動比連線限制允許的更多並行操作。例如，大小符合您連線限制SemaphoreSlim的閘道呼叫：

var throttle = new SemaphoreSlim(50); // match MaxConnectionsPerServer
await throttle.WaitAsync(token);
try
{
    await s3Client.GetObjectAsync(request, token);
}
finally
{
    throttle.Release();
}

設定逾時和重試

逾時和重試對感知效能有直接影響。值Timeout太高可讓停滯的請求區塊長時間。當服務已傳回限流錯誤時，積極的重試政策會新增更多請求，並可能使限流惡化。選擇符合您應用程式延遲與失敗容錯能力的重試政策，並讓真正的例外狀況傳播，而不是以遮罩懸置的方式重試。

如需重試模式、 MaxErrorRetry和 Timeout 屬性 (ReadWriteTimeout 僅適用於 .NET Framework) 的詳細資訊，以及如何設定這些模式的範例，請參閱 重試和逾時。

最佳化串流和大型物件傳輸 (Amazon S3)

若要上傳和下載大型物件或多個物件，請使用 Amazon.S3.Transfer 命名空間中的 TransferUtility 類別。它使用分段傳輸並行上傳和下載，並為您管理串流、組件和連線。這比單一串流傳輸更快，而且是移動大型物件的建議方式。

診斷效能問題

當您調查緩慢、懸置或明顯洩漏時，下列訊號可協助您快速找到原因：