[omniORB] BOA vs POA Performance

[Sai-Lai Lo]

Craig,

I understand from Duncan that your observed performance problem is resolved
if you compile the ORB to not use the poll() system call.

I've re-tested omniORB 3 under HPUX 11.00. There is only a slight
performance panelty when poll() is used.

Therefore I suspect the issue is something to do with bad implementation of
poll() in the 10.20 pthread library. Notice that kernel thread support is
only there in 11.00 and the pthread library in 10.20 is only a user space
implementation.

If you have time, could you try switching the ORB to use select to see if
that makes a difference?

Just edit tcpSocketMTfactory.cc as follows:

Index: tcpSocketMTfactory.cc
===================================================================
RCS file: /project/omni/cvsroot/omni/src/lib/omniORB2/orbcore/tcpSocketMTfactory.cc,v
retrieving revision 1.22.6.19
diff -c -r1.22.6.19 tcpSocketMTfactory.cc
*** tcpSocketMTfactory.cc	2000/10/20 16:39:13	1.22.6.19
--- tcpSocketMTfactory.cc	2000/12/19 13:35:42
***************
*** 286,293 ****
  
  
  #if defined(__hpux__)
! #include <poll.h>
! #define USE_POLL_ON_RECV
  #endif
  
  #if !defined(__VMS)
--- 286,297 ----
  
  
  #if defined(__hpux__)
! #  if __OSVERSION__ >= 11
! #    include <poll.h>
! #    define USE_POLL_ON_RECV
! #  else
! #    define USE_SELECT_ON_RECV
! #  endif
  #endif
  
  #if !defined(__VMS)

Sai-Lai


>>>>> Craig A Roloff writes:

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

> We've tried tracing the ORB calls and they are identical between
> BOA and POA.  We've tried setting a large object hash table and
> disabling locate requests, without any improvements.

> The server is passing a total of about 300K bytes in 4000 calls
> (including locate requests).  We ran puma on the server.
> Both the BOA and the POA servers have 5 threads.  They spend
> essentially all of their time as follows:

> Main)  Blocked in select
> 2)     Running in cma___null_thread/cma__io_available/_select_sys
> 3)     Blocked in omniORB_Ripper::run_undetached/omni_condition::wait
> 4)     Blocked in omniORB_Scavenger::run_undetached/omni_condition::timedwait
> 5)     Blocked in tcpSocketRendezvouser::run_undetached/accept

> The POA server takes 256M user cycles and 1.7G system cycles,
> whereas the BOA server takes 140M user cycles and 220M system
> cycles.  Thus it is appears the POA server is spending more
> of its time just waiting.

> We're at a loss on what to investigate next.  Any ideas?





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