的性能最佳实践 适用于 .NET 的 AWS SDK

如何创建客户端、处理响应和配置应用程序对吞吐量、延迟和内存使用有很大影响。本主题介绍可帮助您的应用程序高效、可靠地运行的使用和配置模式。这些模式在高负载或资源受限的环境（例如容器和无服务器函数）中最为重要。遵循这些做法可以提高性能并防止常见问题，例如响应缓慢、挂起和内存使用率过高。

最有影响力的做法如下：

在开始之前，请务必设置环境并配置项目。

重复使用单个长期服务客户端

诸如 Amazons3Client之类的服务客户端AmazonDynamoDBClient是线程安全的，构造成本相对较高且使用寿命长。 构建客户端可以解析区域和终端节点信息，并建立底层 HTTP 基础架构。为每项服务创建一个客户端，并在应用程序的整个生命周期中重复使用。如果您致电多个区域，请为每个区域创建一个单独的客户端。

在使用依赖注入的应用程序中，将客户端注册为单例。AWSSDK.Extensions.NETCore.SetupNuGet包中的AddAWSService扩展方法将客户端注册的默认生命周期为ServiceLifetime.Singleton。客户端是在第一次请求时创建的，并且在进程的整个生命周期中都会重复使用相同的实例。有关使用依赖注入注册 AWS 服务以及从配置中读取选项的更多信息，请参阅AWSSDK.Extensions.NETCore.Setup 和 iconfiguration。

您也可以手动将客户端注册为单例。

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

重复使用客户端并不意味着你应该停止处理每个操作的响应。在应用程序生命周期内重复使用客户端，但继续处置各个操作返回的响应和流，如中所述处置响应和直播。

处置响应和直播以释放连接

一些 SDK 响应对象带有网络直播流。最常见的示例是 GetObjectResponse，它通过其ResponseStream属性实现IDisposable和公开对象的内容。在完全读取流或处理响应之前，响应会保持开放的 HTTP 连接。如果您泄露了这些响应（例如，通过循环调用GetObject而不处置每个结果），则打开的连接会累积直到连接池耗尽，下一次调用就会阻塞。这是关于第 N 个对象上的下载 “随机挂起” 或停滞的报道背后的原因。

务必将直播响应打包在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");

async/await 正确使用

在现代 .NET 上，中的服务操作 适用于 .NET 的 AWS SDK 是异步的，返回 a 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);
}

异步代码的其他建议：

为配置 .NET 垃圾收集 AWS Lambda 还有亚马逊 ECS

当容器出现 “内存泄漏” 时，.NET 垃圾收集器 (GC) 可能会保留回收的内存以供重复使用。因此，即使托管堆没有增长，进程内存也可能显得很高且稳定。此外，GC 不会自动检测容器的内存限制（其 cgroup 限制）。在受限的环境中，堆可能会向主机的内存而不是容器的极限增长。这可能导致OutOfMemoryException或容器被终止。

为了帮助 GC 在受限的环境中正常运行：

有关这些设置的更多信息，请参阅 learn.microsoft.com 上的垃圾收集运行时配置选项。有关 AWS 计算的特定指导，请参阅 AWS 开发者工具博客文章为 Amazon ECS 配置.NET 垃圾回收和 AWS Lambda。

管理 HTTP 连接和连接限制

在高吞吐量下，两个与连接相关的问题很常见。首先是打开了太多短暂的连接。这会耗尽临时端口，留下套接字，并增加 TCP 和 TLS 握手延迟。TIME_WAIT第二个问题是可用的连接太少，这给并行性带来了瓶颈。重复使用单个长寿命客户端（参见重复使用服务客户端）是健康连接池的基础，因为池化取决于客户端的重复使用。

要调整每个端点的并发连接数，请在客户端配置上设置该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值过高会使停滞的请求长时间阻塞。当服务已经返回限制错误时，激进的重试策略会增加更多请求，并可能使限制变得更糟。选择符合应用程序对延迟和失败容忍度的重试策略，让真正的异常传播，而不是以掩盖挂起的方式重试。

有关重试模式和Timeout属性（仅ReadWriteTimeout适用于.NET Framework）的更多信息以及如何设置它们的示例，请参阅重试和超时。MaxErrorRetry

优化串流和大对象传输 (Amazon S3)

要上传和下载大型对象或许多对象，请使用Amazon.S3.Transfer命名空间中的TransferUtility类。它使用分段传输并行上传和下载，并为您管理流、分段和连接。这比单流传输更快，也是移动大型对象的推荐方式。

诊断性能问题

当您调查减速、挂起或明显泄漏时，以下信号可帮助您快速找到原因：