[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