[omniORB] ORB performance issues

[Grealy Colin]

Hi all,
I have been doing some performance testing with omniorb4.0 on redhat. 
The tests time the length it takes for a client to perform 1000 successive
calls to the remote server, which acknowledges each call with a integer of
value 0, this time is then divided by 1000 to give the average call time.
This method of timing is used to compensate for the lack of granularity in
the Unix timing system calls.

The test passes a fixed length string, of increasing length to the server,
this test is repeated for strings of increasing sizes. In addition, each
test is repeated 8 times, passing increasing number of copies of the string,
from 1 to 8 copies, as parameters to the server.

e.g. in pseudo-code
loop
{
     string_size *= 2;
     char* a1 = new char[string_size];

     start_timer()
     loop 1000 times
     {
           server_obj->op1(a1);
     }
     end_timer();
     output();

     start_timer()
     loop 1000 times
     {
           server_obj->op2(a1,a1);
     }
     end_timer();
     output();

     //etc. up to 8 params
}
test results
ftp://omniorb:omniorb@ftp.startamadeus.ie/pub/orb_tests/Chart_ORB4.xls
ftp://omniorb:omniorb@ftp.startamadeus.ie/pub/orb_tests/timedVarOps100-1-180
102.csv
ftp://omniorb:omniorb@ftp.startamadeus.ie/pub/orb_tests/timedVarOps100-50-18
0102.csv

We found that the time per call spiked at certain parameter sizes, which are
shown on the graph. In some cases a particular size message took 2-3 times
longer then a message a few bytes larger. Has anyone else experienced a
similar problem or does anyone have any light to shine on this issue?

Colin Grealy
Distributed Applications
Traventec
email: colin.grealy@traventec.com
tel:   + 353 91 518725
fax:   + 353 91 525056
web:   www.traventec.com


I hate to advocate drugs, alcohol, violence or insanity to anyone,
but they've always worked for me.
	--Hunter S. Thompson