c# - 异步/等待高性能服务器应用程序？

Question

C# 5 中新的 async/await 关键字看起来很有前途，但我读过一篇关于对这些应用程序的性能影响的文章，因为编译器将为异步方法生成一个非常复杂的状态机。

使用这些关键字进行异步编程要容易得多，但它是否与 SocketAsyncEventArgs for Sockets 一样好？

第二个问题:像 Stream.WriteAsync 这样的异步 IO 方法真的是异步的(.Net 上的完成端口或 Mono 上的 epoll/poll)还是这些方法是将写调用推送到线程池的廉价包装器？

第三个问题:除了 UI 应用程序的 SynchronizationContext 之外，有没有办法实现某种单线程上下文？类似于事件循环的东西，以便完成的任务在主线程上继续？
我发现了 Nito.AsyncEx 库，但我不太确定这是否是我需要的。

Answer 1

async 本身的性能非常好。这方面做了大量工作。

通常，在服务器端，您关心 async I/O。我将忽略 async CPU 绑定(bind)方法，因为 async 开销无论如何都会在噪音中丢失。

异步 I/O 会增加每个请求的内存使用量，但它会减少每个请求的线程使用量。所以你最终赢了(除了临界病理极端情况)。这适用于所有异步 I/O，包括 async 。
await 是用一种模式设计的——不仅仅是 Task 类型——所以如果你需要尽可能多地挤出性能，你可以。

I read an article about the performance impact on those applications since the compiler will generate a quite complex state machine for async methods.

Stephen Toub 的 article you read 很棒。我还推荐 Zen of Async video(也是 Stephen Toub)。

Async-programming using these keywords is so much easier but is it as good as say SocketAsyncEventArgs for Sockets ?

首先，了解 SocketAsyncEventArgs 更具可扩展性，因为它减少了内存垃圾。使用 async 套接字的更简单方法将产生更多内存垃圾，但由于 await 是基于模式的，因此您可以使用 define your own async -compatible wrappers for the SocketAsyncEventArgs API(如 Stephen Toub 的博客所示...我在这里感觉到一种模式；)。这使您可以充分发挥性能。

尽管从长远来看，设计横向扩展系统通常比扭曲代码以避免一些内存分配更好。恕我直言。

Second question: Are asynchronous IO methods like Stream.WriteAsync really asynchronous (Completion Ports on .Net or epoll/poll on Mono) or are these methods cheap wrappers for pushing a write call to a threadpool ?

我不知道 Mono。在 .NET 上，大多数异步 I/O 方法都基于完成端口。 Stream 类是一个值得注意的异常(exception)。默认情况下， Stream 基类将执行“廉价包装”，但允许派生类覆盖此行为。来自网络通信的 Stream 总是覆盖它以提供真正的异步 I/O。如果 流是为异步 I/O 显式构造的，则处理文件的 Stream s 仅覆盖此 。

Third question: Beside the SynchronizationContext of an UI application, is there a way to implement some kind of single-threaded context ?

ASP.NET 也有一个 SynchronizationContext ，所以如果你使用的是 ASP.NET 你已经设置好了。

如果您正在开发自己的基于套接字的服务器(例如 Win32 服务)，那么您可以使用我的 AsyncEx 库中的 AsyncContext 类型。但这听起来并不是你真正想要的。 AsyncContext 将在当前线程上创建一个单线程上下文。但是 async 对服务器应用程序的真正威力来自扩展请求而不是线程。

考虑 ASP.NET SynchronizationContext 的工作原理:当每个请求传入时，它会获取一个线程池线程并构造一个 SynchronizationContext(针对该请求)。当该请求有异步工作要做时，它会向 SynchronizationContext 注册，并且运行该请求的线程返回线程池。稍后，当异步工作完成时，它会获取一个线程池线程(任何线程)，在其上安装现有的 SynchronizationContext，并继续处理该请求。当请求最终完成时，它的 SynchronizationContext 被释放。

该过程的关键在于，当请求正在等待 (await) 异步操作时，没有专用于该请求的线程。由于与线程相比，请求相当轻量级，这使服务器能够更好地扩展。

如果您为每个请求提供一个单线程 SynchronizationContext ，例如 AsyncContext ，即使它无关紧要，这也会将一个线程绑定(bind)到每个请求。这几乎不比同步多线程服务器好多少。

如果您想解决自己的 SynchronizationContext 发明问题，您可能会发现我的 MSDN article on SynchronizationContext 很有用。我还在那篇文章中介绍了异步方法如何“注册”和“安装”上下文；这主要是由 async void 和 await 自动完成的，因此您不必明确地执行此操作。