我创建了一个带有Angular前端和ASP.Net Core 3.1后端的SPA应用程序。我使用典型的RESTful API在两者之间进行通信，并使用基于SignalR的WebSocket API进行一些实时推送状态更新。因为这个应用程序是对旧的Windows.NET程序的重写，所以我有一个使用SqlClient与公共数据库交互的大量代码库。我想重用这个代码，而不是试图将系统转换为EF。我已经完成了所有这些工作，但我开始担心对ExecuteScalar、ExecuteReader和ExecuteNonQuery等函数的调用可能会对IIS中运行的ASP.Net后端的性能产生负面影响。我还需要考虑GetDataAdapter和适配器。填充，但这是另一个问题。
我似乎应该使用异步调用来帮助线程管理，但如果我所做的只是立即等待调用，那么使用同步调用有什么区别吗？同步调用在IIS中等待良好吗？
需要明确的是，我在使用同步或异步调用时没有看到任何问题。我的早期测试没有负荷。我希望我的应用程序可以扩展到大约100个并发用户，也许有一个云主机。这就是为什么我想要做出正确的基本架构决策。
如果重要的话，我的后端在.NET5中运行时没有更改，但我还没有承诺升级。如果.NET 5能提高我的性能，我会考虑升级。
但如果我所做的只是立即等待调用，那么使用同步调用有什么区别吗？
是的，有一个非常显著的区别：它释放了线程，这样线程就可以去做其他有趣的事情，而不是在网络IO上被阻止(以及数据库服务器正在做的任何事情(。Await完全是关于CPU资源(尤其是线程(的可伸缩性，但涉及到一些较小的开销，这可能会使单个请求稍微慢一点，但不会慢到你所能测量到的任何程度。
但就上下文而言：堆栈溢出(其负载远高于此(在IIS上可以很好地扩展(它也在Kestrel中运行所需的(主要使用同步数据库访问(向异步数据访问的转换仍在进行中(。如果你的应用程序不能扩展到100个用户，那么指责同步与异步将是推卸责任：真正的问题可能是由于设计不理想而导致的查询性能不佳。异步不会是决定成败的因素，它只会帮助设计良好的系统进一步扩展。