[Ace-users] Performance issue with a system being migrated from
Orbix 3
andyg
Goodwin.Andy at gmail.com
Wed Jun 20 05:02:49 CDT 2007
To: ace-bugs at cs.wustl.edu
Subject: TAO: Performance issue with a system being migrated from
Orbix
ACE VERSION: 5.5.1
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). 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. 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?
Thanks,
Andrew
REPEAT BY: N/A
SAMPLE FIX/WORKAROUND: N/A
More information about the Ace-users
mailing list