[omniORB] Performance Question

[Sai-Lai Lo]

Dietmar,

We take performance seriously. I think it bears out in our own test and in
all the other tests I've seen on the Web that omniORB2 is among the fastest
ORBs available. The point I was trying to made, perhaps not as clearly as
it should be, is that there are other aspects to an ORB design that can
affect the scaling of an ORB's performance.

I honestly don't know why in Georg's measurment, visibroker performs better
in the local bulk data transfer. It could well be that it is using shared
memory.  Otherwise, I do not see where one can cut the overhead further
than it has been done in omniORB2.

Shared memory for obvious reasons could be faster than a loop back socket
interface. (Is there shared memory support on windows?) There are however
drawbacks in using shared memory. The System V shared memory API, which as
far as I know, is the API for shared memory on all unix platforms is
deficient. The semantics allows shared memory to be allocated and never
clean up if the processes using a shared memory segment died. This is bad
news. A proper way to use shared memory would be to have a shared memory
manager to allocate segments to other processes and look after the cleanup
if these processes misbehave. AFAIK, this is how things are done in the
Oracle database. I do not know if other ORBs that are purported to use
shared memory for local transport have taken the precaution to avoid shared
memory segment being left behind and not cleaned-up when the ORB processes
abort. I may also be totally wrong about shared memory, if so please point
out my mistakes.

I take your point that local bulk data transfer could do better with other
IPC mechanism. It just isn't something that we have time to look into at
this time. I assume everybody is happy to see GIOP 1.2, bi-directional GIOP
for doing callbacks through a firewall, proper codeset conversion support
for wchar and wstring to come sooner.

If anyone wants to create a local IPC transport for omniORB2, it would be
most welcomed. The interfaces to plug in a transport is well-defined and I
have given pointers on how to use the interfaces several times on this
list. 

Regards,

Sai-Lai


>> It seems to me quite a number of people have done similar comparisons. It
>> is more interesting to me to see comparisons that involves multiple
>> concurrent clients doing transfers. Measurements on how much internal
>> buffering an ORB is consuming, etc.

> It is more interesting in our particular case to see comparisons such as
> Georg is doing, with a single client doing transfers, because that's how
> WE need to use omniORB :).

> That is, the primary potential performance bottleneck in our environment
> is a single local connection to a single server transferring several
> megabytes of data per second, possibly for extended periods of time. The
> cost of passing this data via sockets for a local transfer really cuts
> into performance badly!

> The only possible workaround is creating the server as a DLL, and loading the 
> DLL so that it uses virtual function calls. But it seems that defeats one of 
> the reasons we use CORBA in the first place: so that different companies can 
> create different plug-in components (as executables) in a standard manner.

> A possible solution has been suggested in Georg's comment: using shared
> memory for local connections.

> The apparent implication that the omniORB team can't be bothered with
> performance is rather disheartening in light of the obvious pride they
> take in having the "fastest ORB" around. Here's a possible weakness
> that's been demonstrated in omniORB's handling of large data sets. Won't
> your team at least please look at it, rather than dismissing it as
> irrelevant? Because it isn't, at least for us and our customers; and I
> suspect for other companies as well.



-- 
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