CODEWITHSUNDEEP
c#multithreadingwcf
Rich S
Rich S

Reputation: 3455

WCF Slows down with multiple requests

I have a WCF service using basicHttpBinding with a security mode of TransportWithMessageCredential. I'm looking into an issue of timeouts that some of our clients are getting. I've written a little test app, which creates multiple threads on the client, and makes a 'simple' call to the server, which does nothing other than Thread.Sleep for period of time.

When I run this test app, it creates 10 threads, instantiates the object with the remote method, then calls it (telling it to sleep for 5 seconds (5000ms)).

I've also tried with multiple variations of number of threads and 'sleep' time at the server, and I find that the first 3 or 4 return within the correct amount of time, but the subsequent ones all take longer.

1:12:13.197 Starting Test - Multi1 1:12:13.199 Starting Test - Multi2 1:12:13.203 Starting Test - Multi3 1:12:13.228 Starting Test - Multi4 1:12:13.367 Got connection object - Multi3 1:12:13.368 Starting Test - Multi5 1:12:13.368 Got connection object - Multi1 1:12:13.369 Got connection object - Multi4 1:12:13.369 Got connection object - Multi2 1:12:13.391 Starting Test - Multi6 1:12:13.394 Starting Test - Multi7 1:12:13.398 Starting Test - Multi8 1:12:13.531 Got connection object - Multi5 1:12:13.532 Starting Test - Multi9 1:12:13.533 Got connection object - Multi7 1:12:13.535 Got connection object - Multi6 1:12:13.539 Starting Test - Multi10 1:12:13.565 Got connection object - Multi8 1:12:13.687 Got connection object - Multi9 1:12:13.691 Got connection object - Multi10 1:12:18.396 Ended Test - Multi3 1:12:18.396 Ended Test - Multi4 1:12:18.844 Ended Test - Multi2 1:12:19.345 Ended Test - Multi1 1:12:19.844 Ended Test - Multi5 1:12:20.344 Ended Test - Multi7 1:12:20.844 Ended Test - Multi6 1:12:21.349 Ended Test - Multi8 1:12:21.844 Ended Test - Multi9 1:12:22.344 Ended Test - Multi10

So, based on the above results, you can see that all of the threads are created and the 'connection object' is obtained. This takes about 500ms, which isn't too bad considering what it's doing.

Then test Multi3 and Multi4 finish in around 5000ms (exactly as expected) but by the time the 8th, 9th and 10th calls come back, they are taking about 8000-9000ms.

When I monitor this on the server, each thread is unique, and has a different threadId, so it's not fighting with the thread pool.

I have the service throttling set to 50 for all properties.

<serviceThrottling maxConcurrentCalls="50" maxConcurrentInstances="50" maxConcurrentSessions="50"/>

So can't see that this could be causing the delay.

Upvotes: 1

Views: 1270

Answers (1)

Seymour
Seymour

Reputation: 7067

You may need to check and then possibly set the minimum number of threads using the ThreadPool.GetMinThreads and ThreadPool.SetMinThreads method.

The following post, although a bit old, helped our team and may provide you with valuable insight.
http://blogs.msdn.com/b/wenlong/archive/2010/02/11/why-are-wcf-responses-slow-and-setminthreads-does-not-work.aspx

For Reference:
First of all, WCF uses managed I/O threads to handle requests. The CLR ThreadPool keeps a certain number of idle I/O threads from being destroyed. When more I/O threads are needed, they are created by the ThreadPool, which is kind of expensive. The number of idle threads is specified by the “MinIOThreads” setting. You can use the ThreadPool.GetMinThreads() API to check what settings you have for your application. By default in a standalone application, this setting is the number of the CPUs that you have on the machine. For example, on my laptop with 2-core, this setting is 2. Because of this, you would want to bump up this MinIOThreads setting with the ThreadPool.SetMinThreads()

Upvotes: 1

Related Questions