[ace-users] Performance issue with a system being migrated from
Douglas C. Schmidt
schmidt at dre.vanderbilt.edu
Wed Jun 20 05:35:34 CDT 2007
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
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
Thus, if you need more "predictable" help for earlier versions of
ACE+TAO, I recommend that you check out
for a list of companies that will provide you with ACE+TAO commercial
> HOST MACHINE and OPERATING SYSTEM: Sun-Fire-V240, SunOS 5.8,
> TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> COMPILER NAME AND VERSION (AND PATCHLEVEL): SunPRO 5.3, Patch
> THE $ACE_ROOT/ace/config.h FILE: ace/config-sunos5.8.h
> THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE: See
> # Enable smart proxies globally
> 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/
> (used by MPC when you generate your own makefiles): N/A for
> 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
>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
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
In general, TAO tries to avoid using dynamic memory, so its stack will
be larger. This shouldn't be related to the performance issues,
>The server in question is running with the
>following TAO service configuration options (e.g. to prevent nested
> static Client_Strategy_Factory "-ORBClientConnectionHandler rw"
> static Client_Strategy_Factory "-ORBTransportMuxStrategy
> 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
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
and the talk at
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.
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
More information about the Ace-users