我正在创建一个与JavaScript客户端一起使用的新的net core 2.2 API。 Microsoft中的某些示例具有具有所有异步方法的控制器，而某些示例则没有。我的API上的方法是否应该异步。如果这是一个因素，将使用IIS。一个示例方法将涉及调用另一个API并返回结果，而另一个将使用实体Framework进行数据库请求。
答案 0 :(得分：2)
最佳做法是将异步用于控制器方法，尤其是当您的服务正在执行诸如访问数据库之类的操作时。不管您的控制器方法是否异步对于IIS都无关紧要，.net核心运行时将调用它们。两者都可以，但是您应该尽可能尝试使用异步。
答案 1 :(得分：1)
首先，您需要了解异步功能。简而言之，如果线程进入等待状态，它允许将处理请求的线程返回到池中以处理其他请求。这几乎总是由I / O操作（例如查询数据库，写入/读取文件等）引起的。CPU密集型工作（例如计算）需要线程的活跃使用，因此无法异步处理。作为异步的附带好处，是“取消”工作的能力。如果客户端过早关闭连接，则会触发取消令牌，支持的异步方法可以使用该令牌来取消正在进行的工作。例如，假设您将取消令牌传递到对ToListAsync()之类的调用中，并且客户端关闭了连接，则EF将看到此消息并随后取消查询。实际上，它要比这复杂一些，但是您明白了。
因此，您需要简单地评估异步在特定情况下是否有益。如果您要进行I / O和/或希望能够取消正在进行的工作，请进行异步处理。否则，您可以根据需要坚持同步。
这就是说，虽然异步会花费一点性能，但通常可以忽略不计，并且它在可伸缩性方面提供的好处通常值得权衡。因此，始终保持异步非常可取。另外，如果您正在执行异步操作，那么您的操作也应该是异步的。例如，EF Core所做的一切都是异步的。 “同步”方法（ToList而非ToListAsync）仅阻塞异步方法。因此，如果您通过EF进行查询，请使用async。同步方法仅用于支持某些有限的场景，这些场景只能处理同步，在这种情况下，应在单独的线程（Task.Run）中运行以防止死锁。
更新
我还应该提到，动作（尤其是Razor Page处理程序）有点模糊。有一个完整的请求管道，动作/处理程序只是其中的一部分。进行“同步”操作并不排除在视图或某些策略处理程序，视图组件等中执行异步操作。仅当操作本身正在执行某种异步工作时，该操作本身才需要是异步的。
特别是Razor Page处理程序通常会被同步，因为处理程序本身通常很少进行处理。全部都在下级流程中。
答案 2 :(得分：0)
异步是了解非常重要的概念和微软过于注重这一点。但有时我们并没有意识到这一点的重要性。不使用异步每次卡住调用程序线程。
<强>为什么使用异步
即使你的API控制器是采用单一的操作（比方说，DB提取），你应该使用异步。原因是你的服务器的线程数量有限，处理客户请求。假设您的应用程序可以处理20个请求，并且如果您不使用异步，那么您将阻塞处理程序线程以执行该操作（数据库操作），而该操作可以由其他线程（异步）完成。反过来，由于您的主线程正忙于处理其他事情并且无法照看新的请求，因此请求队列会增加，在某个阶段您的应用程序将停止响应。如果你想使用异步主线程是免费的处理，同时在后台运行其它更多的运行客户端的请求。
更多资源
我会建议绝对看微软非常丰富的官方视频上的性能问题。 https://www.youtube.com/watch?v=_5T4sZHbfoQ