glassfish
  1. glassfish
  2. GLASSFISH-15391

[PERF] Client-Side ORB requests have 3x performance regression

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1_b35
    • Fix Version/s: 3.1_ms08
    • Component/s: orb
    • Labels:
      None

      Description

      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.

      1. orb.tgz
        2.76 MB
        Ken Cavanaugh

        Issue Links

          Activity

          Hide
          Ken Cavanaugh added a comment -

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

          Show
          Ken Cavanaugh added a comment - Performance regression should be fixed in ORB b021, integrated in GF rev 44286.
          Hide
          Ken Cavanaugh added a comment -

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

          Show
          Ken Cavanaugh added a comment - I've fixed the problem in get_effective_component (it threw NPE if get_effective_components return null) and updated the orb.tgz file.
          Hide
          Ken Cavanaugh added a comment -

          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.

          Show
          Ken Cavanaugh added a comment - 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.
          Hide
          Ken Cavanaugh added a comment -

          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.

          Show
          Ken Cavanaugh added a comment - 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.

            People

            • Assignee:
              Ken Cavanaugh
              Reporter:
              Scott Oaks
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: