CODEWITHSUNDEEP
c#performancemultithreadingservice
George2
George2

Reputation:

multithread performance problem for web service call

Here is my sample program for web service server side and client side. I met with a strnage performance problem, which is, even if I increase the number of threads to call web services, the performance is not improved. At the same time, the CPU/memory/network consumption from performance panel of task manager is low. I am wondering what is the bottleneck and how to improve it?

(My test experience, double the number of threads will almost double the total response time)

Client side:

class Program
{
    static Service1[] clients = null;
    static Thread[] threads = null;

    static void ThreadJob (object index)
    {
        // query 1000 times
        for (int i = 0; i < 100; i++)
        {
            clients[(int)index].HelloWorld();
        }
    }

    static void Main(string[] args)
    {
        Console.WriteLine("Specify number of threads: ");
        int number = Int32.Parse(Console.ReadLine());

        clients = new Service1[number];
        threads = new Thread[number];

        for (int i = 0; i < number; i++)
        {
            clients [i] = new Service1();
            ParameterizedThreadStart starter = new ParameterizedThreadStart(ThreadJob);
            threads[i] = new Thread(starter);
        }

        DateTime begin = DateTime.Now;

        for (int i = 0; i < number; i++)
        {
            threads[i].Start(i);
        }

        for (int i = 0; i < number; i++)
        {
            threads[i].Join();
        }

        Console.WriteLine("Total elapsed time (s): " + (DateTime.Now - begin).TotalSeconds);

        return;
    }
}

Server side:

    [WebMethod]
    public double HelloWorld()
    {
        return new Random().NextDouble();
    }

thanks in advance, George

Upvotes: 4

Views: 13720

Answers (9)

Engin Ozturk
Engin Ozturk

Reputation: 41

IIS AppPool "Maximum Worker Processes" is set to 1 by default. For some reason, each worker process is limited to process 10 service calls at a time. My WCF async server-side function does Sleep(10*1000); only. This is what happens when Maximum Worker Processes = 1 http://s4.postimg.org/4qc26cc65/image.png

alternatively

https://i.sstatic.net/QknP8.png

(First post on SO, I need to combine all pictures into one picture.)

The client is making 48 async WCF WS calls in this test (using 16 processes). Ideally this should take ~10 seconds to complete (Sleep(10000)), but it takes 52 seconds. You can see 5 horizontal lines in the perfmon picture (above link) (using perfmon for monitoring Web Service Current Connections in server). Each horizontal line lasts 10 seconds (which Sleep(10000) does). There are 5 horizontal lines because the server processes 10 calls each time then closes that 10 connections (this happens 5 times to process 48 calls). Completion of all calls took 52 seconds.

After setting Maximum Worker Processes = 2 (in the same picture given above) This time there are 3 horizontal lines because the server processes 20 calls each time then closes that 20 connections (this happens 3 times to process 48 calls). Took 33 secs.

After setting Maximum Worker Processes = 3 (in the same picture given above) This time there are 2 horizontal lines because the server processes 30 calls each time. (happens 2 times to process 48 calls) Took 24 seconds.

After setting Maximum Worker Processes = 8 (in the same picture given above) This time there is 1 horizontal line because the server processes 80 calls each time. (happens once to process 48 calls) Took 14 seconds.

If you don't care this situation, your parallel (async or threaded) client calls will be queued by 10s in the server, then all of your threaded calls (>10) won't get processed by the server in parallel.

PS: I was using Windows 8 x64 with IIS 8.5. The 10 concurrent request limit is for workstation Windows OSes. Server OSes doesn't have that limit according to another post on SO (I can't give link due to rep < 10).

Upvotes: 0

Jason Hernandez
Jason Hernandez

Reputation: 2969

You are not seeing any performance gain because there is none to be had. The one line of code in your service (below) probably executes without a context switch most of the time anyway.

return new Random().NextDouble();

The overhead involved in the web service call is higher than than the work you are doing inside of it. If you have some substantial work to do inside the service (database calls, look-ups, file access etc) you may begin to see some performance increase. Just parallelizing a task will not automatically make it faster.

-Jason

Upvotes: 2

DaBro
DaBro

Reputation:

Try to use some processor consuming task instead of Thread.Sleep. Actually combined approach is the best.

Sleep will just pass thread's time frame to another thread.

Upvotes: 0

markt
markt

Reputation: 5156

Of course adding Sleep will not improve performance.

But the point of the test is to test with a variable number of threads. So, keep the Sleep in your WebMethod.

And try now with 5, 10, 20 threads.

If there are no other problems with your code, then the increase in time should not be linear as before.

You realize that in your test, when you double the amount of threads, you are doubling the amount of work that is being done. So if your threads are not truly executing in parallel, then you will, of course, see a linear increase in total time...

I ran a simple test using your client code (with a sleep on the service). For 5 threads, I saw a total time of about 53 seconds. And for 10 threads, 62 seconds. So, for 2x the number of calls to the webservice, it only took 17% more time.. That is what you are expecting, no ?

Upvotes: 1

markt
markt

Reputation: 5156

I don't believe that you are running into a bottleneck at all actually.

Did you try what I suggested ?

Your idea is to add more threads to improve performance, because you are expecting that all of your threads will run perfectly in parallel. This is why you are assuming that doubling the number of threads should not double the total test time.

Your service takes a fraction of a second to return and your threads will not all start working at exactly the same instant in time on the client.

So your threads are not actually working completely in parallel as you have assumed, and the results you are seeing are to be expected.

Upvotes: 3

markt
markt

Reputation: 5156

As bruno mentioned, your webmethod is a very quick operation. As an experiment, try ensuring that your HelloWorld method takes a bit longer. Throw in a Thread.Sleep(1000) before you return the random double. This will make it more likely that your service is actually forced to process requests in parallel. Then try your client with different amounts of threads, and see how the performance differs.

Upvotes: 0

markt
markt

Reputation: 5156

Although you are creating a multithreaded client, bear in mind that .NET has a configurable bottleneck of 2 simultaneous calls to a single host. This is by design. Note that this is on the client, not the server.

Try adjusting your app.config file in the client:

<system.net>
<connectionManagement>
    <add address=“*” maxconnection=“20″ />
</connectionManagement></system.net>

There is some more info on this in this short article :

Upvotes: 7

bruno conde
bruno conde

Reputation: 48265

Well, in this case, you're not really balancing your work between the chosen n.º of threads... Each Thread you create will be performing the same Job. So if you create n threads and you have a limited parallel processing capacity, the performance naturally decreases. Another think I notice is that the required Job is a relatively fast operation for 100 iterations and even if you plan on dividing this Job through multiple threads you need to consider that the time spent in context switching, thread creation/deletion will be an important factor in the overall time.

Upvotes: 0

gbjbaanb
gbjbaanb

Reputation: 52659

My experience is generally that locking is the problem: I had a massively parallel server once that spent more time context switching than it did performing work.

So - check your memory and process counters in perfmon, if you look at context switches and its high (more than 4000 per second) then you're in trouble.

You can also check your memory stats on the server too - if its spending all its time swapping, or just creating and freeing strings, it'll appear to stall also.

Lastly, check disk I/O, same reason as above.

The resolution is to remove your locks, or hold them for a minimum of time. Our problem was solved by removing the dependence on COM BSTRs and their global lock, you'll find that C# has plenty of similar synchronisation bottlenecks (intended to keep your code working safely). I've seen performance drop when I moved a simple C# app from a single-core to a multi-core box.

If you cannot remove the locks, the best option is not to create as many threads :) Use a thread pool instead to let the CPU finish one job before starting another.

Upvotes: 5

Related Questions