[omniORB] BOA vs POA Performance

[Duncan Grisby]

On Friday 8 December, "Craig A. Roloff" wrote:

> We have an HP-UX 10.20 client/server application we want to
> upgrade from omniORB 2.8.0 (BOA) to omniORB 3.0.2 (POA).  The
> conversion was relatively simple but the resulting performance
> is perplexing -- the POA version runs an order of magnitude
> slower.

The POA does add some overhead, but it's minimal. You certainly
shouldn't be seeing such an enormous difference.

> The server and the client run on the same machine (indeed they
> are parent and child processes).  When we try all four of the
> BOA/POA combinations only the POA server combinations are slow.
> When using either the BOA or POA client with the BOA server, the
> application runs in 11 seconds.  When using either client with
> the POA server, the application runs in 140 seconds.

This sounds very similar to a problem we've seen on Linux. When client
and server are in different processes on the same machine, so the TCP
loopback is being used, there is a very odd pattern of performance. A
simple program which does several thousand requests containing an
octet sequence fluctuates wildly in execution time. Something like

  Seq. Size     Time to complete test

    10000            <  0.1 secs
    20000            > 10   secs
    30000            <  0.1 secs
    40000            > 10   secs
    50000            <  0.1 secs

and so on. It only does that through the loopback interface. Across a
network, the time increases roughly linearly with sequence size, as is
expected.

The problem seems to be that omniORB 3 is more aggressive with sending
data in large lumps than omniORB 2 was. That ought to make it faster,
but it seems to interact badly with the Linux loopback interface.
Maybe HP-UX is the same. Is there any way you can test your program
across a network, to see if the performance improves?  Another
possibility is trying on a different OS, to see if the problem is
HP-UX specific.

We were ignoring the Linux problem, in the hope that the Linux
loopback interface would be fixed. If the problem is more wide-spread,
maybe we'll look into work-arounds for it.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --