5

Why would WCF services configured with instancing per call and multiple concurrency would perform differently when run with different process and totally differently when called from threads?

I have one application which does distribute data through number of threads and makes calls (don't think that locking occurs in code, will test that again) to WCF service. During test was noticed that increasing number of threads in distribution app does not increase overall performance of wcf processing service, average is about 800 mpm(messages per minute processed) so throughput does not really change BUT if you run second application then average throughput increases to ~1200 mpm.

What am i doing wrong? what have i missed? i can't understand this behavior.

UPDATE #1(answer to questions in comments)

Thanks for such quick responses. Max connections is set to 1000 in config(yes in system.net). Referring to this article wcf Instances and threading max calls should be 16 x number of cores, so i assume if called form ~30 threads on 2 cpu wcf service should accept mostly all of those thread calls?

Does it have anything to do with shared memory? because that's probably the only differences between multiple threads and processes, i think.

Don't have a opportunity to right now to test it with more cpu's or single. Will do when can.

Weazel
  • 63
  • 6
  • Are you testing this in a single CPU core environment? I would guess there are multiple cores involved. Try and run your test in a single core environment. – Quality Catalyst May 12 '15 at 05:49
  • What transport are you using? – Damien_The_Unbeliever May 12 '15 at 07:08
  • try to increase maxconnection value in system.net section of your application config (not wcf config) ` ` – Sohaty May 12 '15 at 07:17
  • I would guess that the slowdown is due to context switching between threads. – tom redfern May 12 '15 at 10:25
  • @weazel, Have you tried to increase naxconnection value? http://www.danielroot.info/2009/02/improve-net-web-client-performance-by.html – Sohaty May 13 '15 at 06:10
  • @TomRedfern i am not sure if i understood it, what is this context switching between threads? every thread makes call using WebClient, in very simple old fashioned threading way, i think i have checked all the places where lock might occur it shouldn't be stuck in any place – Weazel May 13 '15 at 07:23

2 Answers2

0

So I think to understand this behavior, you first need to understand how WCF processes calls with per-call instancing. The hint is in the name - Per Call.

Every call any client makes is serviced by a new instance of the service (the exception to this is reentrancy, but this is not important in your scenario).

So, configuring service concurrency makes no practical difference to the service behavior. Regardless of whether the calls are coming from a single, multithreaded client, or multiple clients, the service will behave the same: it will create a service instance per call.

Therefore, the difference in overall system performance must be due to something on the client side. If I had to take a wild guess I would say that the one client is slower than two clients because of the cost associated with context switching which is mitigated (via an unidentified mechanism) by running the client in in two separate processes.

If I am correct then you should be able to get the highest performance per thread by running multiple single-threaded clients, which is a test you could do.

Community
  • 1
  • 1
tom redfern
  • 30,562
  • 14
  • 91
  • 126
0

In this implementation of operation, below attribute should be added to class.

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)]
public class MyService : IMyService
{
}

You can read more here: http://wcftutorial.net/Per-Call-Service.aspx

Ankit Vijay
  • 3,752
  • 4
  • 30
  • 53
avinash247
  • 1