使用异步 I/O 与多线程的响应式桌面应用程序答案

【问题标题】：Responsive desktop application using Asynchronous I/O vs Multi-threading使用异步 I/O 与多线程的响应式桌面应用程序
【发布时间】：2015-07-27 04:33:02
【问题描述】：

我有用 c# 和 WPF 编写的 .Net 桌面应用程序。没有用于加载数据的直接后端数据库。视图数据通过托管在多个 Web 服务器上的不同类型的 Web 服务使用。

以下是应用程序中使用的不同类型的 Web 服务

Java SOAP 网络服务
Java RESTful 服务
.Net 服务栈服务
WCF 服务

因此，为了在应用程序的特定视图中显示数据，我同步使用了大约 100 多个不同的服务。如果所有服务都被同步消费，off course application 将不会响应。为了使应用程序响应，我使用了多线程。也就是说，我在非 UI 线程中调用了所有 Web 服务。所有这些 Web 服务都是使用不同的 .net 库同步调用的。平均而言，使用 Web 服务获取所有数据并将其呈现在 UI 中大约需要 60 到 90 秒。

目前我正在研究应用程序性能优化。我的想法是，使用多个线程是应用程序缓慢的问题之一。没有真正做任何基准测试。这只是我的想法。
当我们查看调用多个 Web 服务的操作时，属于 I/O 绑定操作，而不是 CPU 绑定操作。由于我在线程上同步调用了所有 Web 服务，因此它变成了 CPU 绑定操作。

因此，为了提高应用程序性能，我正在考虑将所有同步调用转换为异步 I/O 调用而不使用显式线程。我用于调用 Web 服务的所有 Dot Net 库都支持异步 I/O 调用。

通过从使用多线程进行的同步调用转移到异步 I/O 调用，我会在性能上获得相当大的改进吗？有人做过基准测试吗？

【问题讨论】：

如果线程池中有大量线程并且上下文切换率很高，那么迁移到异步可以提高性能。

标签： c# multithreading asynchronous async-await

【解决方案1】：

实际上没有做过任何基准测试。

那你绝对应该。您从基准测试中学到的一件事是，您对问题所在的直觉几乎总是不正确的。

由于我在线程上同步调用了所有的 Web 服务，所以它变成了一个 CPU 密集型操作。

在后台线程中调用 Web 服务不会将它们变成 CPU 绑定操作。它们仍然是 IO，但有一个阻塞线程等待它完成。没有任何 CPU 受此约束。

通过从使用多线程进行的同步调用转移到异步 I/O 调用，我是否会获得相当大的性能改进？

这实际上取决于您对上下文切换的痛苦程度。必须同时查询 100 个服务以获取数据似乎确实很多，尤其是如果每个服务都消耗一个线程。这一切都缩小到您如何进行基准测试。请注意，如果您正在编写一个 UI 应用程序，您很可能也仅限于 ServicePointManager.DefaultConnectionLimit，默认情况下为 2。

异步是关于提供可扩展性。如果您的应用程序 IO 很重，您可能会从进行更改中受益。再次，对您的代码进行基准测试，没有办法。

【讨论】：