Quote Originally Posted by dilettante View Post
This really isn't what multithreading is for. In your case you are creating too many threads and killing yourself on threading overhead and synchronization.

If you have a legit need to run this many Web Service calls in parallel use async requests, a much more efficient use of resources than multithreaded blocking calls. The real answer is probably to rip and redesign the Web Service to handle multiple requests and return multiple response-sets per call. The "Let's pretend Web Services are procedure calls" style of architecture is very inefficient. It is like making a separate database query for every row you need to get back - only worse.
Actually, this is for testing purpose. I am testing for the response time of the web service. The reason for using multiple threads to make requests is to simulate a situation where multiple clients (in my case, 30 clients) are trying to make requests. I thought I could simulate 30 clients by creating 30 threads (within the same process). But I've noticed that if I was to split the threads by half, one process will run 15 threads and another process run the other 15 threads, it performs a little better than if I ran 30 threads in a single process. I know you mentioned about async requests, but let's assume that is not an option. Is this simply just how threads behave when too many are created within the same process?