在不更改服务合同的情况下获得 Async/Await 的服务器端优势答案

【问题标题】：Gaining the server side benefits of Async/Await without changing the service contract在不更改服务合同的情况下获得 Async/Await 的服务器端优势
【发布时间】：2019-09-25 21:22:20
【问题描述】：

花了一些时间在谷歌上搜索，但没有找到明确的答案，也不知道如何通过测试来证明它（欢迎提出建议）。

我们有一个 WCF 服务，该服务带有一个循环等待特定事件发生的方法。在循环中，它使用 Thread.Sleep 等待 100 毫秒，这在服务中是很长的（我们想重新设计它。在服务中睡眠不是一个好主意吗？）。

我想通过使方法异步并改用 Task.Delay 来提高吞吐量，而不更改服务合同。在使方法异步并重新生成合同类之后，合同签名似乎是完整的。我还可以看到生成的代码现在有一个状态机，似乎表明它现在是异步的。

我的问题是，即使我以同步方式调用异步服务方法，我是否会从线程可用于其他工作中受益？框架会等待服务方法吗？

【问题讨论】：

方法的调用者是服务的客户端。这不是内部调用。所以框架处理方法的调用。我想知道这是否会通过 Await 来完成（从而在我的代码等待某些东西时释放线程以进行其他服务调用）。
服务器和客户端之间不发送任务。因此，服务器不关心请求是否由具有任务的客户端处理。服务器所知道的关于客户端的所有信息都是请求负载，而且它必须发送回响应负载。
好吧，这似乎是合理的。因此，异步方法的服务器端优势与客户端使用服务的方式无关？

标签： c# wcf async-await

【解决方案1】：

我的问题是，即使我以同步方式调用异步服务方法，我是否会从线程可用于其他工作中获益？

所以异步方法的服务器端好处与客户端使用服务的方式无关？

异步独立于服务器端和客户端。服务器上的异步可实现更高的可扩展性（这可能会或可能不会增加吞吐量）。客户端上的异步可实现 UI 响应。

网络通信在这里是一个“分隔符”，因此任何一方都可以异步或同步处理它，独立于其他应用程序。

【讨论】：

感谢您的澄清。这些符合我对其工作原理的有限看法。这是否意味着服务器会自动等待服务中调用的任何异步方法？
您的代码必须有 await 语句用于它自己调用的方法。 If the entry point of your service implementation returns a Task<T>, then the WCF framework will await it internally.
好的，感谢您的精彩解释。我刚刚意识到我错过了让具有 OperationContract 属性的方法返回一个任务。猜猜我现在错过了内部等待？
从最底层的方法开始最简单，例如，将Thread.Sleep 更改为await Task.Delay。编译器将从那里引导您：将该方法更改为 async 并在任何调用它的地方使用 await 等等。您最终将使用您的服务实现方法。
是的，我实际上是这样做的。我只是不确定 wcf 框架是否会等待它。感谢您的澄清。