Friday, September 7, 2012

Performance with Silverlight calling WCF service , not solved by binary message encoding

Performance with Silverlight calling WCF service , not solved by binary message encoding

I'm having an issue where calling a WCF web service from Silverlight is very slow. The situation is very similar to the one outlined in http://forums.silverlight.net/t/148027.aspx/1 . Like that poster, I have set up a simple Silverlight Application project and a simple Console Application project. In each, I added a service reference to my WCF service and added a few test calls to the service. However, the time it takes for each call to go out is drastically different. The console app makes the call on the order of milliseconds. The Silverlight app makes it anywhere from 3-5 seconds.

In the post I linked to above, when the poster changed his service to use binary message encoding, the speed gap disappeared. However, in my situation, the large speed gap remains regardless of whether I'm using binary message encoding or text message encoding.

What could account for this speed difference? I've verified through fiddler that both the request and response are being binary-encoded when I have it configured to use my binary endpoint. I've also verified that the slow speed persists through multiple consecutive web service calls, so it can't just be spin-up time. The problem has to be on the Silverlight side somewhere.

Here's a snippet of the code that I'm using to measure the time difference:

    var proxy = new WCFRef.WebServicesClient("binary");     var callbegin = DateTime.Now;     proxy.CallWSMethodAsync();     var callend = DateTime.Now;     var span = callend.Subtract(callbegin);     Debug.WriteLine("call time: " + span.Seconds + "." + span.Milliseconds + " sec"); 

The timespan captured in that code is the span I was talking about with the large difference between console (few milliseconds) and SL (few seconds).

Answers & Comments...




No comments:

Post a Comment

Send us your comment related to the topic mentioned on the blog