[ace-users] Performance issue with a system being migrated from Orbix 3

[Douglas C. Schmidt]

Hi Andy,

   Thanks for using the PRF.

>    ACE VERSION: 5.5.1

ACE 5.5.1 is rather old.  I recommend you upgrade to ACE+TAO+CIAO
x.5.8 (i.e., ACE 5.5.8, TAO 1.5.8, and CIAO 0.5.8), which you can
download from

http://download.dre.vanderbilt.edu

under the heading: "Latest Beta Kit".

The DOC groups at Washington University, UC Irvine, and Vanderbilt
University only provide "best effort" support for non-sponsors for the
latest release, as described in

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-process.html

Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out

http://www.dre.vanderbilt.edu/support.html

for a list of companies that will provide you with ACE+TAO commercial
support.

>    HOST MACHINE and OPERATING SYSTEM: Sun-Fire-V240, SunOS 5.8,
>SOLARIS 8
>
>    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>
>    COMPILER NAME AND VERSION (AND PATCHLEVEL): SunPRO 5.3, Patch
>111678-21
>
>    THE $ACE_ROOT/ace/config.h FILE: ace/config-sunos5.8.h
>
>    THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE: See
>below...
>
>	# Enable smart proxies globally
>	smart_proxies=1
>	include $(ACE_ROOT)/include/makeinclude/platform_sunos5_sunc++.GNU
>	# Only make required service libraries.
>	# This overrides the setting in $TAO_ROOT/orbsvcs/orbsvcs/Makefile.
>	TAO_ORBSVCS = Naming CosEvent ImplRepo
>
>    CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/
>default.features
>    (used by MPC when you generate your own makefiles): N/A for
>Solaris
>
>    AREA/CLASS/EXAMPLE AFFECTED: N/A
>
>    DOES THE PROBLEM AFFECT:
>        COMPILATION? No
>        LINKING? No
>        EXECUTION? Yes
>        OTHER (please specify)? No
>
>    SYNOPSIS: Performance issue with a system being migrated from
>Orbix
>
>    DESCRIPTION:
>
>We are experiencing a performance issue with a r/t control system that
>we are currently migrating from Orbix (CORBA 2.1) to TAO. We have a
>particular server that hosts many 1000's of CORBA  objects. These
>objects are mainly accessed internally within the server, so to reduce
>the CORBA overhead we are using the direct co-location option.
>Unfortunately we are still seeing a significant performance overhead
>while internally accessing these objects (factor of 5 greater than
>with Orbix).

Hum, that's pretty weird - direct collocation should be very fast.
Are you certain that the calls are actually collocated, i.e., is it
possible that the calls are going through the network loopback?

>There are many instances of CORBA references being passed
>internally as parameter arguments, where the CORBA object itself
>typically represents a large buffer of (say) a 10K sequence of octets
>(i.e. typedef sequence <octet>). We also note the TAO call stack is
>significantly larger than the equivalent Orbix call stack for all
>CORBA-related operations.

In general, TAO tries to avoid using dynamic memory, so its stack will
be larger.  This shouldn't be related to the performance issues,
however.

>The server in question is running with the
>following TAO service configuration options (e.g. to prevent nested
>upcalls)
>    static Client_Strategy_Factory "-ORBClientConnectionHandler rw"
>    static Client_Strategy_Factory "-ORBTransportMuxStrategy
>exclusive"
>    static Client_Strategy_Factory "-ORBConnectStrategy blocked"
>    static Resource_Factory        "-ORBFlushingStrategy blocking"
>    static Resource_Factory        "-ORBConnectionCacheMax 100"
>Does anyone know if there are other optimizations we can try?

Sure, there are all sorts of things you can try.  I recommend you check out 

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/performance.html

and see if any suggestions there help.  You might also try running a
profiler (e.g., IBM Rational's "quantify") to see where the overhead
is occurring.  You might also consider using the FOCUS tool that's
described in the paper at

http://www.cs.wustl.edu/~schmidt/PDF/MW-Spl.pdf

and the talk at 

http://www.cs.kuleuven.be/conference/EuroSys2006/slides/eurosys06-vu-talk.ppt

I believe that Johnny Willemsen <jwillemsen at remedy.nl> from Remedy has
some experience using FOCUS with various customers, so you might want
to talk with him, as well.

Thanks,

        Doug
-- 
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Vanderbilt University                        WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203                          NET: d.schmidt at vanderbilt.edu