[GLASSFISH-15391] [PERF] Client-Side ORB requests have 3x performance regression Created: 30/Dec/10  Updated: 19/Dec/16  Resolved: 06/Jan/11

Status: Closed
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File orb.tgz    
Issue Links:
blocks GLASSFISH-13944 [PERF] specj enterprise 2010 benchmar... Closed
Tags: 3_1-approved, PSRBUG


Rich client ORB requests have regressed in general as much as 3x due to the client-side libraries.

The profile for 3.X show that as the request is being sent, it makes its way down to com.sun.corba.ee.impl.interceptors.ClientRequestInfoImpl.getEffectiveComponents(). In 3.0.1, that takes a very small amount of time (.09 seconds in our test), and its major contributor is OMGSystemException.invalidComponentId (.038 seconds).

In 3.1, that leads into $Proxy.invalidComponentId() which itself takes 17.4 seconds for the same number of requests (5k). That call goes through CompositeInvocationHandlerImpl.invoke() and then into the logex.WrapperGenerator.

Comment by Ken Cavanaugh [ 31/Dec/10 ]

The basic problem here is a bad decision in the design of the PortableInterceptor API: there is no standard
API for checking whether or not a given IOR contains a tagged component with a particular ID, other than to
call get_effective_component(s) and catch the exception if no component with the ID is present. This affects
GF 3.1 in the JTS InterceptorImpl class, where send_request calls get_effective_component, and just ignores
a null result.

The code in the ORB's ClientRequestInfoImpl.get_effective_components implementation always throws an
exception when no tagged component with the given ID is present. I think I may modify this method so that
when the ORB is running in GF, it simply returns a null. This violates the OMG PI specification, but
it is probably a good solution in the specific case of the ORB in GF. I thought I made such a
modification long ago, but I can't find it now.

As a separate issue, I may look into dynamic code generation for the exception wrappers in 3.2, avoiding the
considerable overhead imposed by using dynamic proxies. But in any case, avoiding the throw of an exception
that is always ignored (for every request not using transactions) is a bad design regardless of the
efficiency of the underlying exception handling mechanism.

Comment by Ken Cavanaugh [ 03/Jan/11 ]

I've attached a version of the ORB that won't through an exception when
get_effective_components can't find the ID: it returns null instead.
This version also remove the synchronization in SynchronizedHolder that
seems to be causing the regression in 15392.

Comment by Ken Cavanaugh [ 04/Jan/11 ]

I've fixed the problem in get_effective_component (it threw NPE if
get_effective_components return null) and updated the orb.tgz file.

Comment by Ken Cavanaugh [ 06/Jan/11 ]

Performance regression should be fixed in ORB b021, integrated in GF rev 44286.

Generated at Wed Apr 26 02:37:45 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.