[omniORB] omniORB performance

[Sai-Lai Lo]

This topic have been discussed several times on the list. Have a look at
this posting to see if it answer your question:

http://www.uk.research.att.com/omniORB/archives/1997-06/0048.html

By the way, the current omnioORB implementation have to walk through all
the arguments to calculate the total size before doing the real
marshalling. The reason for doing so is to keep the marshalling buffer
small while it can handle arbitrarily large arguments. 

In the new GIOP engine:

1. With GIOP 1.1 and 1.2, there is no need to pre-calculate the total size
   because a request or reply can be splited to multiple fragments.

2. With the good old GIOP 1.0, there is *also* no need to pre-calculate the
   total size *if* in the end the request/reply size is small enough to fit
   into the marshalling buffer (around 8K). If the request size turns out
   to be bigger, then the ORB will walk through all the arguments and
   calculate the size.

In practice, the need to calculate argument size is a very small overhead
unless you have very complex arguments. 

While we are on the subject of performance, I might as well mention this.
There seems to be a general believe that doing sequential string matching
to match an operation name with the upcall routine is inefficent and "high
performance" ORBs should do something like hashing or binary tree
search. We did some measurements and find that simple string match is
actually faster for small number of operations defined in an interface. The
picture reverses as the number of operations increases but the yield point
is at least tens of if not over 100 operations. It seems to me it is hard
to find in real use an interface with over 100 operations or else it is a
really fat interface that can do with some weight loss exercises.

Sai-Lai


>>>>> Zeljko Rajic writes:

> Hi !
> As I was a little bit astonished about the omniORB performance (it is
> faster than VisiBroker), I've read the paper "The Implementation of a
> High Performance ORB over Multiple Network Transports", written by
> Sai-Lai Lo and Steve Pope that is said to explain these performance
> achievement.

> They write that omniORB uses a 'thread-per-connection' model. Now I'm
> not sure if I understood everything correctly. They write that for every
> connection a separate thread is spawned.
> Does this now mean that for every client only one connection is
> established to handle the requests or as many connections as are
> necessary?  What happens for example when the client spawns 20 threads
> that in parallel invoke operations on the same/different object(s) ??

> Does omniORB multiplex the requests from this 20 threads onto one
> connection or are some new connections established ??  If new
> connections are established, how does omniORB recognize that it should
> open a new connection ??

> I hope that somebody in this list can answer these questions.


> Regards,
> Zeljko



-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND