[GLASSFISH-15391] [PERF] Client-Side ORB requests have 3x performance regression Created: 30/Dec/10 Updated: 19/Dec/16 Resolved: 06/Jan/11
|Reporter:||Scott Oaks||Assignee:||Ken Cavanaugh|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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
The code in the ORB's ClientRequestInfoImpl.get_effective_components implementation always throws an
As a separate issue, I may look into dynamic code generation for the exception wrappers in 3.2, avoiding the
|Comment by Ken Cavanaugh [ 03/Jan/11 ]|
I've attached a version of the ORB that won't through an exception when
|Comment by Ken Cavanaugh [ 04/Jan/11 ]|
I've fixed the problem in get_effective_component (it threw NPE if
|Comment by Ken Cavanaugh [ 06/Jan/11 ]|
Performance regression should be fixed in ORB b021, integrated in GF rev 44286.