C# 使用异步I/O与多线程的响应型桌面应用程序

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

下面是应用程序中使用的不同类型的web服务

JavaSOAPWeb服务

Java RESTful服务

.Net服务堆栈服务

WCF服务

因此，为了在应用程序的特定视图中显示数据，我同步使用了大约100多个不同的服务。如果同步使用所有服务，则场外应用程序将不会响应。为了使应用程序具有响应性，我使用了多线程。也就是说，我在非UI线程中调用了所有web服务。所有这些web服务都是使用不同的.net库同步调用的。平均来说，使用web服务获取所有数据并在UI中呈现大约需要60到90秒

目前我正在进行应用程序性能优化。我的想法是，使用多线程是应用程序缓慢的问题之一。没有做过任何基准测试。这只是我的想法。
当我们看到调用多个web服务的操作属于I/O绑定的操作，而不是CPU绑定的操作。因为我在线程上同步调用了所有web服务，所以它变成了一个CPU受限的操作

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

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

没有做过任何基准测试

那你绝对应该。你从基准测试中学到的一件事是，你关于错误的直觉几乎总是不正确的

因为我在线程上同步调用了所有web服务，所以它变成了一个CPU受限的操作

在后台线程中调用web服务不会将它们转换为CPU绑定的操作。它们仍然是IO，但有一个阻塞的线程在等待它完成。没什么能限制你的

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

这真的取决于你有多痛苦。必须同时查询100个服务中的数据似乎非常多，尤其是当每个服务都使用一个线程时。这一切都局限于你如何进行基准测试。请注意，如果您正在计算UI应用程序，则很可能还限于

ServicePointManager.DefaultConnectionLimit

，默认值为2

---

Async是关于提供可伸缩性的。如果你的应用程序是IO密集型的，你可能会从更改中受益。同样，要对代码进行基准测试，这是不可能的。

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