I'm currently writting an application that make a huge lot of call to slow webservices (I had no say in that pattern) that produce little output.
I'd like to make like 100 parallel calls (I know real parallelism can only go as far as you have cores).
But I was wondering if they were performance differences between different approach.

I'm hesitating between:

Using Task.Factory.StartNew in a loop.

Using Parallel.For.

Using BackgroundWorker.

Using AsyncCallback.

...Others?

My main goal, is to have as many webservices calls being started as quickly as possible.
How should I proceed?

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

Async is the way to go, if you can use .Net 4.5. Because it uses I/O completion ports where possible it reduces the number of threads in use drastically. Threads are hugely expensive, so this is much better.
–
Matthew WatsonMay 13 '13 at 15:05

As Matthew Watson said. Async is the way to go. It's designed to do what you're trying to do.
–
Will CalderwoodMay 13 '13 at 15:13

2

@Serge even with "lightning fast speed", you cannot avoid delays from the network. A remote call that returns immediately takes at least 50 ms in very good conditions. That does not look like a lot, but compared to the execution time of a standard program, it feels like an eternity.
–
FalanweMay 13 '13 at 16:01

2 Answers
2

From a performance standpoint it's unlikely to matter. As you yourself have described, the bottleneck in your program is a network call to a slow performing web service. That will be the bottleneck. Any differences in how long it takes you to spin up new threads or manage them is unlikely to matter at all due to how much they will be overshadowed by the network interaction.

You should use the model/framework that you are most comfortable with, and that will most effectively allow you to write code that you know is correct. It's also important to note that you don't actually need to use multiple threads on your machine at all. You can send a number of asynchronous requests to the web service all from the same thread, and even handle all of the callbacks in the same thread. Parallelizing the sending of requests is unlikely to have any meaningful performance impact. Because of this you don't really need to use any of the frameworks that you have described, although the Task Parallel Library is actually highly effective at managing asynchronous operations even when those operations don't represent work in another thread. You don't need it, but it's certainly capable of helping.

According to your advices I used Async (with I/O event) while I was previously using TLP.
Async really does outperform Sync + Task usage.

I can now launches 100 requests (almost?) at the same time and if the longest running one takes 5 seconds, the whole process will only last 7 seconds while when using Sync + TLP it took me like 70 seconds.

In conclusion, (auto generated) Async is really the way to go when consuming a lot of webservices.