[omniORB] omniORB slow transfer when clientCallTimeOutPeriod != 0
Duncan Grisby
duncan at grisby.org
Tue Aug 11 13:41:01 BST 2009
On Tuesday 11 August, Igor Lautar wrote:
> Now, the obvious solution is to use timeouts on calls. This is fine, but it
> has a nasty sideeffect: transfer is slow as hell (20x decrease in 1 Gbit
> network).
[...]
> Notice the difference between time taken to do sendChunk (size 20) and
> inputMessage (size 24).
> In case where there is no timeout set, time is 10 milliseconds, and where
> there is a timeout, time is 191 milliseconds.
That sounds like a bug in Windows that means nonblocking sockets impose
ridiculous delays if you do large transfers:
http://support.microsoft.com/kb/823764
In my experiments, the default transfer and socket send buffer sizes
that omniORB uses are suitable to avoid the delays, but there must be
something about your access pattern that triggers it. Your trace shows
that much of the data for the call is sent as a single large transfer
(the sendCopyChunk message), which could be the trigger.
Try modifying the values of the maxSocketSend and / or socketSendBuffer
parameters. In particular, try setting maxSocketSend to something
smaller than socketSendBuffer.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list