4

There are a lot of similar questions, but they all deal with server-side slowness - this is all about client-side issues.

1st call takes 900ms. 2nd call takes 20 ms.

I narrowed the slowness on the first call to serviceProxy.Method(). Fiddler reports that the actual time on the wire for the 1st call is 16 ms. Since the 2nd call is massively faster, I am forced to conclude the problem occurs with some WCF client-side instantiation code that fires when the first method call takes place.

Facts:

  • The connection to the server occurs via wsHttpBinding
  • The objects are encoded with the Protobufs.NET library by Marc Gravell
  • Questions here on SO that do address client-side issues like mine recommend making the 1st call on a background thread to just get the slowness out of the way. However, that's addressing the symptoms, not the underlying cause.

Any ideas why the slowdown occurs on the 1st post?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
AngryHacker
  • 59,598
  • 102
  • 325
  • 594
  • This is a common topic around the Interwebs. It's mostly attributed to the overhead of the WCF framework loading and initializing the first time. – Cᴏʀʏ Sep 30 '11 at 01:17
  • Duplicate of: http://stackoverflow.com/questions/3350960/wcf-performance-slow-for-the-first-call, http://stackoverflow.com/questions/4289357/wcf-service-startup-takes-extra-time – Cᴏʀʏ Sep 30 '11 at 01:20
  • Not so sure ... Those articles talk about IIS app pool spin up time. In his question he stated that even though the request took a long time, the server round trip time in Fiddler showed 16 ms which rules out IIS spin up - it's time on the client if that's true. – bryanmac Sep 30 '11 at 01:28
  • @bryanmac You are correct. The IIS is already spun up and warm. Definitely not IIS. I can see the small pause in Fiddler before the call even appears. The second call appears immediately. – AngryHacker Sep 30 '11 at 05:23
  • which version of protobuf-net are you using? – Marc Gravell Sep 30 '11 at 12:10
  • @MarcGravell On the first call, the protobufs lib is taking about 0.2 seconds to get going (if I am reading this [profiler output](http://imgur.com/c5YnM) right). – AngryHacker Sep 30 '11 at 21:50
  • If you want the absolute fastest spin-up, v2 supports pre-generating the serialisation assembly; this would perhaps shave *some* time - bit not the WCF time – Marc Gravell Sep 30 '11 at 22:04
  • @MarcGravell Can you please point me to a link on pre-generating the serialisation assemblies vis a vis protobufs? Is [this](http://stackoverflow.com/questions/6491256/is-it-possible-to-create-a-protobuf-net-serialization-assembly-for-silverlight-an) what you had in mind? RuntimeTypeModel.Compile? – AngryHacker Oct 01 '11 at 05:08
  • @AngryHacker yes, but note that you can use that as a build tool to generate a separate assembly that you use for serialisation. In most cases that is overkill, though; we don't use that for StackOverflow, and we are performance-crazed. – Marc Gravell Oct 01 '11 at 07:51
  • @bryanmac Not really, but I worked around the problem. I defer making the first call as far out as I can. Meanwhile on app start, I make a dummy call (that returns nothing) via WCF on a separate thread. This way, by the time, I need to make an actual call, WCF has loaded. I played around with pre-generating protobuf serialization assemblies, but it wasn't really worth it, since the library is pretty fast already. tl;dr worked around the problem. – AngryHacker Nov 20 '11 at 05:21

1 Answers1

2

A common server slowness on start is IIS app pool spin up but in your question you stated that even though the first request was 900 ms, only 16 ms was spent on the server request according to fiddler. If that's true, it suggests something is going on client side.

One possibility is that some client apps that serialize objects generate and compile serialization code for those data types at runtime, which can result in slow start-up performance

http://msdn.microsoft.com/en-us/library/aa751883.aspx

http://msdn.microsoft.com/en-us/library/ms733901.aspx

I'm not familiar with protobuffs but compiling serialization code is trade off which makes the first call significantly slower but makes subsequent calls faster.

Not sure if that's your initial cost but it's a possibility.

bryanmac
  • 38,941
  • 11
  • 91
  • 99
  • The idea to pre-gen serialization libraries produces huge perf gains when using simple XmlSerialization, cause it's so slow and cpu-intensive to begin with. Not so much with protobufs. – AngryHacker Nov 20 '11 at 05:23