[omniORB] slow transfer speed for certain sequence lengths

[Claudio Scafuri]

Hello,

I am testing the performances of various ORBs, and I noticed a strange
behaviour of
omniORB 3.0.4.

In one of the tests a sequence of data is sent from client to server.
For certain lengths
of the sequence the time needed by the call jumps to a very high and
nearly constant value of about 40 ms. For example, the first "window"
for a sequence of integers is between 339 an 518 elements. Outside this
window the time is less than 1 ms. There are other slow windows for
longer sequnece lengths.

The problem seems to be in the omniORB client side implementation. The
same client program, but compiled with another ORB (TAO, ORBacus)
behaves in a more predictable way: the time of the call grows more or
less linearly with the sequence length, without any "window". The server
program is compiled with omniORB.

On the other hand, the window effect appears if a use an omniORB client
with a server compiled with another ORB , in this case the windows
limits vary a little, for tao: 339-519,
for ORBacus: 337-516.


The tests are carried out on the following platforms:

client: linux R.H 6.2 i686, gcc 2.95.1

server: linux ppc, derived form MontaVista,on power pc MVME1500 Motorola
board, kernel 2.4.18, gcc 2.95.4

network: switched 100 Mb ethernet.


If both client and server are run on the linux i686, the numbers change
a little, but the behavour is the same; the window is now 944-519, the
"slow response" time is a little less
than 10 ms.


I also carried out some preliminary tests with omniORB 4. The slow
behaviour appears almost immediately, but I have not yet found the upper
limit of the window. But if I use the unix sockets transport, I do not
notice any degradation of performance for any length of
the sequence.

I hope these informations may help you to improve this very good ORB.
Outside the "bad windows" it is the fastest ORB I tested, and with a
very reasonable memory footprint.

Sincerely yours

Claudio Scafuri