Need to speed up processing on background thread


  • I've a C# WPF client/Server application. I've an autocomplete search texbox on top of my xaml screen for filtering on various products list.On the bottom of the screen, I've a Product details screen.For every

    product selected in the search box,I show the product details.

    As of now,we've 400 products in the database.We get product details from our db and also other product details using a third party web service using http. The products list could increase over a period of time.

    There's a wcf windows service running on our app server.Its job is to fetch product list and details for each product.Client communicates with this service using tcp


    We restart this service every at about 11pm. When the service restarts,we do some basic tasks in the service constructor and open the wcf communication channel. And then we spawn a background thread(using asnyc/await

    design pattern) to fetch "list of products and its details". We need to make sure this background thread is completed in the least possible amount of time.

    Can I use Task.Parallel for achieving this?Also, may be I can add a logic in which I dynamically increase the number of tasks depending upon the number of products. For eg.for 400 products, I could spawn 10 tasks...each task would process 40 products.For 800 products, 20 tasks...and so on so forth.

    Does this make sense?Or is there any other better way of achieving this please?


    Wednesday, April 19, 2017 5:05 AM

All replies

  • As to your last question, "Can I use Task.Parallel [...] dynamically increase the number of tasks depending upon the number of products," the easiest way to achieve this would be to use a Parallel.Foreach loop. This will spawn as many tasks as can be executed simultaneously given the number of CPUs, up to the limit of the number of items in the collection.

    However, this will not help you unless your speed is limited by the local CPU processing of the products that you are downloading. But most likely, your limiting factor is, instead, the speed of the http communications channel that you use to call the web service, and the overhead to open and tear down the communication channel.

    If this is the case (which you should verify by doing some benchmarking), then a better solution would be to alter the service and client so that a single request will download many or all products in a "single trip", rather than attempting to launch many threads each of them trying to download one product.

    Wednesday, April 19, 2017 5:49 AM