.net5.0 Web api 中数据库的 Async-Await api 性能瓶颈

Question

.net5.0 Web API
由于客户端广泛使用的 API 很少，因此整体性能正在恶化。因此，我们决定将这些选定的 API 转换为 Async/Await，以减少 IIS 的负载。
实施相同的方法后，我们在本地环境中约 100 个并行请求（通过 jMeter）时获得了更好的性能。但一旦我们将负载增加到 200 个请求，它就开始出现以下错误：

“从池中获取连接之前超时时间已过。发生这种情况可能是因为所有池连接都在使用中并且已达到最大池大小。”

我们意识到我们并没有完全提高性能，而是将瓶颈从 IIS 转移到了数据库。
为了解决这个问题，我们尝试更改连接字符串（My SQL Server）属性，即最大池大小、ConnectRetryCount、ConnectRetryInterval 等，这确实有效并为我们提供了更好的结果，但一切都需要权衡。增加最大池大小将利用数据库服务器资源。
另外，我们永远无法预测有多少并行请求会到达我们的 API，即如果我的最大池大小是 400，如果有 450 个并行请求到达，它仍然会中断。

我们确定了一些选项，例如使用 SemaphoreSlime，来限制到达数据库的请求数量，这不会打开太多连接，从而限制超时错误。但在这里我们无法充分利用我的 api 的异步特性。

是否有优化的解决方案，或者我们遗漏了什么？
另外，如果我们选择使用 SemaphoreSlime，它的安全性如何？

Answer 1

IIS 和 Kestrel 可以配置限制最大连接数，那么为什么要使用自己自制的解决方案呢？

您可以通过增加连接超时而不是使用

SemaphoreSlim

来实现相同的目标。

如果您想增加应用程序的吞吐量，您应该开始优化查询，如果这还不够，您应该考虑增加数据库服务器硬件资源。

如果最大池大小为 400 并且有 450 个并发请求到达，则不一定会中断。如果池中没有可用连接，

Connection.OpenAsync

将等待，直到有可用连接。因此，如果查询足够快，就不会超时。

Answer 2

这里有两个可以提高系统性能的建议：

1. 缩短工作时间，从而减少并行工作：

   • 使用在本地完成工作的存储过程，而不是在 api 和数据库之间移动数据
   • 扩大数据库规模，
   • 优化查询
   • 确认索引
   • 使用缓存
   • 等等

2. 接受请求，但将它们放入队列中，并让队列的消费者批量处理它们，而不是逐一处理。