views:

263

answers:

2

My performance measurements of synchronous WCF calls from within a Silverlight application showed I can make 7 calls/s on a localhost connection, which is very slow. Can this be speeded up, or is this normal?

This is my test code:

const UInt32 nrCalls = 100;
ICalculator calculator = new CalculatorClient(); // took over from the MSDN calculator example
for (double i = 0; i < nrCalls; ++i)
{
    var call = calculator.BeginSubtract(i + 1, 1, null, null);
    call.AsyncWaitHandle.WaitOne();
    double result = calculator.EndSubtract(call);
}

Remarks:

  • CPU load is almost 0%. Apparently, the WCF module is waiting for something.
  • I tested this both on Firefox 3.6 and Internet Explorer 7.
  • I'm using Silverlight v3.0
  • For comparison: I've once written an IPC library in C++ and a similar test yielded some 4000 calls/s. That was without the HTTP packet wrapper, but I don't expect that to slow things down much. It's just that 7 calls/s is so incredibly slow.

Update: I've ported the client side from Silverlight to .NET, and this solved the performance problem. In that test, synchronous calls are made at 140 calls/s (instead of 7 calls/s), and asynchronous calls at 200 calls/s (instead of 16 calls/s). Apparently, the slowness is inherent to the Silverlight platform. I'll have to learn to live with it.

+3  A: 

Not a lot. You run the problem of making 100 http calls, that just takes time. You arelady do not blow it by generating a new client every time.... so, sorry.

In general, this is a bad example (or: a good one showing bad practice). Services should always be coarse grained to avoid the call overhead. A service should have some "weight" in what it does, generally.

A calculator may accept an array of operations, so all 100 calculations can be sent at once, for example.

Keep that in mind when when designing your own interfaces.

TomTom
"100 http calls just take time": Agreed, but 7 calls/s is so incredibly slow. I've written an IPC library in C++ and a similar test yielded some 4000 calls/s. That was without the HTTP packet wrapper, but I don't expect that to slow things down much.
Dimitri C.
+1  A: 

Use async calls and run them in parallel.

The internet is only so fast. As it is, you send a request, wait for an eternity for (1) the message to reach the server, (2) the server to respond, (3) the response to travel back. (1) and (3) take time; there are things like 'miles to the server' and 'the speed of light' in play, maybe. And then you send the next request and do the same waiting game again. And again. In a loop.

Hence async calls and parallel requests = win.

(Hint: if you use F#, async can be very easy, as in the sample below.)

open System
open System.Diagnostics 
open System.ServiceModel 

let binding = new BasicHttpBinding()
let address = "http://YOURSERVERMACHINENAME:11111/Blah"

#if SERVER
[<ServiceContract>]
type IMyContract =
    [<OperationContract>]
    abstract member Subtract : x:int * y:int -> int

type MyService() =
    interface IMyContract with
        member this.Subtract(x,y) = x-y

let host = new ServiceHost(typeof<MyService>, new Uri(address))
host.AddServiceEndpoint(typeof<IMyContract>, binding, address) |> ignore
let smb = new Description.ServiceMetadataBehavior()
smb.HttpGetEnabled <- true
host.Description.Behaviors.Add(smb)
host.Open()
Console.WriteLine("service is open")

#else

[<ServiceContract(Name="IMyContract")>]
type IMyClientContract =
    [<OperationContract>]
    abstract member Subtract : x:int * y:int -> int
    [<OperationContract(AsyncPattern=true)>]
    abstract member BeginSubtract : x:int * y:int * c:AsyncCallback * o:obj -> IAsyncResult
    abstract member EndSubtract : r:IAsyncResult -> int

let client = ChannelFactory<IMyClientContract>.CreateChannel(binding, new EndpointAddress(address))
let MAX = 30

let syncSw = Stopwatch.StartNew()
[1..MAX] |> Seq.iter (fun i -> 
    let r = client.Subtract(i,1)
    Console.WriteLine(r))
Console.WriteLine("sync took {0}ms", syncSw.ElapsedMilliseconds)

let AsyncSubtract(x,y) = Async.FromBeginEnd(x, y, client.BeginSubtract, client.EndSubtract)

let asyncSw = Stopwatch.StartNew()
[1..MAX] |> Seq.map (fun i -> async {
    let! r = AsyncSubtract(i,1)
    Console.WriteLine(r)}) 
    |> Async.Parallel |> Async.RunSynchronously |> ignore
Console.WriteLine("async took {0}ms", asyncSw.ElapsedMilliseconds)
#endif

Console.WriteLine("press a key to quit")
Console.ReadKey()
Brian
"The internet is only so fast": Hm. I'm only using a loopback connection (127.0.0.1), so it isn't the network that is causing the large delay.
Dimitri C.
Darn. I spent like 15 mins trying to figure out how to disable the firewall just so I could try that sample across two machines before posting it. :)I'd still try them in parallel, even if it means you just call BeginSubtract in the loop and store the results in an array of waithandles, and then WaitAll the handles, and then call EndSubtract again in a loop, to see how much difference that makes.
Brian
"15 mins": I first felt a little guilty, but it was in my original question :-)
Dimitri C.
"I'd still try them in parallel...": I tried this already. In this "semi-sync" scenario, I get 16 calls/s. In the asynchronous scenario (with callbacks) I get the same performance. All this is very slow.
Dimitri C.
Hmmm, any difference with non-silverlight client? Anything funky with data/message contracts (e.g. hitting JIT/NGEN issues that http://msdn.microsoft.com/en-us/library/bk3w6240(VS.80).aspx might fix in non-SL case)? Might be worth making one call, sleeping for a bit, and then making the calls in a loop, to ensure no other 'startup time' costs being measured?
Brian
"startup time": No, that's not my problem, as I get the same result when running the test twice.
Dimitri C.
Do you think 16 calls/s is a normal speed? Have you used WCF in Silverlight?
Dimitri C.
I have not used WCF in SL, but I cannot imagine it could be that slow. I am curious to know behavior of a different client; perhaps the server is throttling things?
Brian
"I am curious to know behavior of a different client": Well, I have implemented a prototype of a self-made IPC library over Silverlight, using HttpWebRequest at the lowest level, and it showed *exactly* the same performance issue. I'm really beginning to think it is an issue with a Nagle-like issue with the outgoing message buffer.
Dimitri C.
By the way: thanks a lot for your time!
Dimitri C.
"perhaps the server is throttling things": I'm almost sure it doesn't, as I had the same perfommance problem when using HttpWebRequest together with our well-tested C++ IPC server.
Dimitri C.