响应式桌面应用程序使用异步I/O vs多线程

本文关键字：vs 多线程 异步 桌面 应用程序 响应 | 更新日期: 2023-09-27 18:04:40

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

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

  1. Java SOAP web服务
    2. Java RESTful service
  2. 。网络服务栈服务
    3. WCF服务

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

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

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

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

响应式桌面应用程序使用异步I/O vs多线程

没有做过任何基准测试。

那你一定要去。你从基准测试中学到的一件事是，你对错误的直觉几乎总是不正确的。

由于我在线程上同步调用了所有web服务，因此它成为了CPU绑定操作。

在后台线程中调用web服务不会把它们变成CPU绑定的操作。它们仍然是IO，但是有一个阻塞的线程等待它完成。CPU不受此限制

通过使用多线程从同步调用移动到异步I/O调用，我将获得相当大的性能改进吗?

这真的取决于你有多受上下文转换的困扰。必须并发地查询100个服务的数据似乎相当多，特别是当每个服务都消耗一个线程时。这一切都缩小到你的基准。请注意，如果您正在编写一个UI应用程序，那么您很可能也仅限于ServicePointManager.DefaultConnectionLimit，它在默认情况下是2。

Async是关于提供可伸缩性。如果你的应用是IO密集型的，你可能会从这个改变中受益。同样，基准测试你的代码，没有办法。

相关文章：