I have to blog about this - as I spent a few days having nightmares about it.
An operation from a websphere service was returning a pdf string, for a payload of about 500KB. The WCF client consuming the service was working fine on the test fixture, but when the operation was integrated in the web solution, with the exact same binding and endpoint, the client was hanging for more than a minute onto the response of this particular operation (every other operation with a smaller payload was OK) before coming back with the deserialized response.
I initially blamed the service, but then noticed (sniffing traffic via fiddler) the response was coming back quick enough and only then the client would hang for more than a minute obviously trying to deserialize or God knows what.
After quite a bit of hacking around on and off, I managed to change the transportmode config setting on the binding from buffered to streamed (I had nothing else left to try!), and it did the trick. In light of this it's pretty obvious that the response was being chunked in parts the size of the buffer and that was probably slowing down the whole process.
Morale of the story: if you've got big payloads transportMode="Streamed" could save your sorry ass.
4 comments:
Interesting but... 500 KB is a very small payload. I don't think it's a "transportMode" related problem. I think the issue it at communication/netwrok level. Try to use a real network sniffer instead of Fiddler.
my 2 cents
fabrizio
Thanks for the input - 500KB is small indeed (but bigger than the rest of the payloads I was working with).
I tried any other solution known to me and this is the only one that did the trick.
Behind the exact same network it works OK outside of the web project, meaning that going through IIS is causing this delay to arise. That's why I excluded probs at network level.
Any other suggestion that might explain the issue is welcome!
Perhaps I was not so clear. Sorry.
My suggestion is to compare the network traffic in the two case. In particular, in the second case (slow one), check if the client is blocked "internally" or it is wainting for something on the network.
As far as I can see (from fiddler) the full response envelope comes back very quickly - but after that the client hangs for more than a minute.
Not sure how I would I go about checking if it's waiting for smt else other than the response! :)
Post a Comment