[omniORB] Bad performance with oneway invocation
Serguei Kolos
Serguei.Kolos at cern.ch
Mon Jul 14 18:38:56 BST 2003
Hello
I'm evaluating now two ORBs: TAO and omniORB, making comparison of their
functionality and performance. I wrote a simple IDL file:
interface Echo
{
oneway void oneway_echo();
void twoway_echo();
};
and implemented server and client applications in both TAO1.3 and
omniORB 4.0.1.
The server creates one object and prints out it's IOR, the client takes
this IOR and
then in a loop makes 100000 remote invocations of requested type and
calculates mean
time for a single invocation.
Doing the tests I obtained the following results:
1. The normal (two-way) invocation round-trip time is about 40% better
with the omniORB
(the time is ~420 us for TAO and ~260 us for the omniORB).
2. The asynchronous (oneway) round-trip time is from 3 to 10 times worse
with the omniORB.
Let me explain: Using the default configuration I got ~60 us time
per invocation with TAO
and ~600 us per invocation for the omniORB.
I have found immediately that this huge time in omniORB produced by
a large number of threads,
which the server starts to process asynch requests coming over
single connection. I set then
the maxServerThreadPerConnection to 1 and then get only one thread
processing all the
requests and obtained ~160 us time per invocation (which is already
much better then before, but
still much worse then with TAO).
What is also interesting is that:
1. If I use the omniORB client with the TAO server the time is even
better - ~35 us
2. If I use the TAO client with the omniORB server the time is again
bad - ~180 us.
If I'm not doing anything particularly stupid, then there is an issue
for the oneway methods
in the omniORB. Can this issue be resolved with the proper configuration
of the omniORB server
or with the next omniORB release?
Thanks
Sergei
PS: I was running my tests on two Linux boxes (RedHat 7.3 kernel 2.4.20)
with gcc 3.2.
The boxes are dual pentium 1GHz with 512 Mb. Server and client always
run on different
machines.
More information about the omniORB-list
mailing list