在 ASP.Net Core 3.1 中等待 SqlClient 调用的最佳方法

Question

我使用 Angular 前端和 ASP.Net Core 3.1 后端创建了一个 SPA 应用程序。 我使用典型的 RESTful API 在两者之间进行通信，并使用基于 SignalR 的 WebSocket API 进行一些实时推送状态更新。 因为这个应用程序是对旧程序 Windows .NET 程序的重写，所以我有一个使用 SqlClient 与公共数据库交互的大量代码库。 我想重用这段代码，而不是尝试将系统转换为 EF。 我已经完成了所有这些工作，但我开始担心调用 function s（如 ExecuteScalar、ExecuteReader 和 ExecuteNonQuery）可能会对在 IIS 中运行的 ASP.Net 后端的性能产生负面影响。我还需要考虑 GetDataAdapter 和 adapter.Fill 但那是一个不同的问题。

看来我应该使用异步调用来帮助线程管理，但如果我所做的只是立即等待调用，那么使用同步调用有什么不同吗？ 同步调用在 IIS 中是否等待得很好？

明确地说，我没有发现使用同步或异步调用有任何问题。 我的早期测试没有负载。 我希望我的应用程序可以扩展到大约一百个并发用户，也许使用云主机。 这就是为什么我想做出正确的基本架构决策。

如果重要的话，我的后端在 .NET 5 中运行时没有任何变化，但我还没有承诺升级。 如果 .NET 5 可以提高我的性能我会考虑升级。

Answer 1

但是如果我所做的只是立即等待调用，那么使用同步调用有什么不同吗？

是的，有一个非常显着的区别：它释放线程，而不是被阻塞 on.network IO（无论您的数据库服务器正在做什么），该线程可以 go 并做其他有趣的事情。 Await 是关于 CPU 资源（尤其是：线程）的可扩展性的，但是涉及到一些小的开销，这些开销可能会使单个请求稍微变慢，但不会达到您曾经衡量过的任何数量。

但对于上下文：Stack Overflow（负载比这高得多）在 IIS（它也在所需的 Kestrel 中运行）上可以很好地扩展，主要使用同步数据库访问（到异步数据访问的转换仍在进行中）。 如果您的应用程序不能扩展到 100 个用户，将责任归咎于同步与异步将推卸责任：真正的问题可能是由于次优设计导致的查询性能不佳。 异步不会成为成就或破坏它的东西 - 它只会帮助设计良好的系统进一步扩展。