CODEWITHSUNDEEP
c#multithreadingasynchronousasync-await
Saran
Saran

Reputation: 935

Responsive desktop application using Asynchronous I/O vs Multi-threading

I have .Net desktop application written in c# & WPF. There is no direct back end database used to load the data. Data for the views are consumed through different types of web services hosted on multiple Web Server.

Below are the different types of web services consumed in the application

  1. Java SOAP web service
  2. Java RESTful service
  3. .Net Service Stack Service
  4. WCF Service

So to show the data in the particular view of the application I consume around 100+ different services synchronously. Off course application will not be response if all the services are consumed synchronously. To make the application responsive, I have used the multi-threading. That is, I invoked all the web services in non-UI thread. All these web services are invoked synchronously using different .net libraries. On an average approximately it takes around 60 to 90 seconds to get all the data using web services and render it in UI.

Currently I am working on the application performance optimization. My thought was that, using multiple threads is one of the problems for application slowness. Not really done any bench marking. It is just my thought.
When we look at operation of making calls to multiple web services belong to the I/O bound operation and not a CPU bound operation. Since I invoked all the web services synchronously on the thread, it became a CPU bound operation.

So to improve the application performance I am thinking of converting all the synchronous calls to Asynchronous I/O call without using explicit thread. All the Dot Net libraries which I used for invoking the web services are having the support for the Asynchronous I/O call.

Will I get considerable amount of improvement on performance by moving from synchronous call made using multi-threading to Asynchronous I/O call? Is anybody did some bench marking?

Upvotes: 1

Views: 313

Answers (1)

Yuval Itzchakov
Yuval Itzchakov

Reputation: 149598

Not really done any bench marking.

Then you definitely should. One thing you learn from benchmarking is that your intuition as to regarding what's wrong is almost always incorrect.

Since I invoked all the web services synchronously on the thread, it became a CPU bound operation.

Invoking web services in background threads doesn't turn them to CPU bound operations. They're still IO, but with a blocked thread waiting for it to complete. Nothing CPU bound by that.

Will I get considerable amount of improvement on performance by moving from synchronous call made using multi-threading to Asynchronous I/O call?

That really depends on how much you're suffering from context-swithing. Having to query 100 services for data concurrently does seem like quite alot, especially if each consumes a thread. It all narrows done to how you benchmark. Note that if you're compusing a UI application, you're most likely also limited to ServicePointManager.DefaultConnectionLimit, which is by default 2.

Async is about offering scalability. If your app is IO heavy, you may benefit from making the change. Again, benchmark your code, no way around that.

Upvotes: 1

Related Questions