glassfish
  1. glassfish
  2. GLASSFISH-19893

performance hotspot in org.glassfish.jersey.server.ApplicationHandler.initialize

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.0_b79
    • Fix Version/s: 4.0_b87_RC3
    • Component/s: jax-rs
    • Labels:
      None

      Description

      During a profiling run, the Jersey service startup in GF takes 8763 ms, and 6165 ms of that is in one method:

      18.1% - 6,165 ms - 1 inv. org.glassfish.jersey.server.ApplicationHandler.initialize

      Is it expected that this method would take quite a bit a time?

      None of the methods that are called by that method take nearly that much time:

      • validate takes 1491ms
      • 37 invocations of org.glassfish.jersey.server.model.Resource.from take 1302 ms

      Nothing else takes more than 1000 ms.

      Note: the times are distorted because of the profiling so just compare the relative times. The 18% is the total CPU time of the process.

        Activity

        Hide
        Tom Mueller added a comment -

        Martin, please continue to work on evaluating what takes more than 900 ms to initialize. This is huge relative to the rest of the server initialization time. I also suspect that this initialization time is effecting the overall devx_web test run.

        Here's a simple test that would seem to demonstrate this. I ran two versions of a script. The first is like the devx_web test:

        asadmin start-domain
        time asadmin deploy helloworld.war
        asadmin undeploy helloworld
        asadmin stop-domain

        The second is similar, except it adds a sleep 3 after the start-domain:

        asadmin start-domain
        sleep 3
        time asadmin deploy helloworld.war
        asadmin undeploy helloworld
        asadmin stop-domain

        In the second test, the server is given time to finish the Jersey/command framework initialization before the deploy starts. If this initialization is not effecting the benchmark time, then this test should show deploy times that are the same in both versions. Here are the results:

        no sleep: 3.34 sec (average of 10 runs)
        with sleep: 2.77 sec (average of 10 runs)

        This shows that the initial deployment of an application could be over a half a second faster if the server was really ready to process a command after the domain is started.

        Show
        Tom Mueller added a comment - Martin, please continue to work on evaluating what takes more than 900 ms to initialize. This is huge relative to the rest of the server initialization time. I also suspect that this initialization time is effecting the overall devx_web test run. Here's a simple test that would seem to demonstrate this. I ran two versions of a script. The first is like the devx_web test: asadmin start-domain time asadmin deploy helloworld.war asadmin undeploy helloworld asadmin stop-domain The second is similar, except it adds a sleep 3 after the start-domain: asadmin start-domain sleep 3 time asadmin deploy helloworld.war asadmin undeploy helloworld asadmin stop-domain In the second test, the server is given time to finish the Jersey/command framework initialization before the deploy starts. If this initialization is not effecting the benchmark time, then this test should show deploy times that are the same in both versions. Here are the results: no sleep: 3.34 sec (average of 10 runs) with sleep: 2.77 sec (average of 10 runs) This shows that the initial deployment of an application could be over a half a second faster if the server was really ready to process a command after the domain is started.
        Hide
        martin.mares added a comment -

        Tom:
        Today I was back in this task. Trying determine what we can do and what initialization is consist of. I found following possibilities - topics for future investigation (overal init is 900ms):

        1. install of base set of Jersey Binders (about 20 binders) takes 240ms. - TODO: Investigate these binders
        2. Validation: 120ms - TODO: Ask Jersey to be possible switch it off. As I wrote before reduction of resources does not help much
        3. Resources introspection: 100ms - TODO: Try to use programmatic API. But I am expecting that it helps just tens of milis.
        4. Stage building 110ms - TODO: Just try to understand this process. But I don't thing that it will be place to reduce init time
        5. Initialisation of component providers 90ms - TODO: Check if we need it and what is it.
        Show
        martin.mares added a comment - Tom: Today I was back in this task. Trying determine what we can do and what initialization is consist of. I found following possibilities - topics for future investigation (overal init is 900ms): install of base set of Jersey Binders (about 20 binders) takes 240ms. - TODO: Investigate these binders Validation: 120ms - TODO: Ask Jersey to be possible switch it off. As I wrote before reduction of resources does not help much Resources introspection: 100ms - TODO: Try to use programmatic API. But I am expecting that it helps just tens of milis. Stage building 110ms - TODO: Just try to understand this process. But I don't thing that it will be place to reduce init time Initialisation of component providers 90ms - TODO: Check if we need it and what is it.
        Hide
        martin.mares added a comment -

        Currently I have two major ideas:
        a) Reflect older idea from Marek and ask Jersey to make validation optional based some configuration variable. Validation takes 120ms on my environment.
        b) Currently working on Jersey's plugin to ServiceFinder implementation. It is already plug-able but I want to ask for revision or maybe small API improvement from Jersey team. I don't want to destroy something. If my measurements are OK my plugin can improve performance for aprox 200ms.
        Overal initialization takes 900ms these two improvements can change it to 600ms. It looks good - so, cross fingers.

        Show
        martin.mares added a comment - Currently I have two major ideas: a) Reflect older idea from Marek and ask Jersey to make validation optional based some configuration variable. Validation takes 120ms on my environment. b) Currently working on Jersey's plugin to ServiceFinder implementation. It is already plug-able but I want to ask for revision or maybe small API improvement from Jersey team. I don't want to destroy something. If my measurements are OK my plugin can improve performance for aprox 200ms. Overal initialization takes 900ms these two improvements can change it to 600ms. It looks good - so, cross fingers.
        Hide
        martin.mares added a comment -
        • What is the impact on the customer of the bug?

        Solution improves performance of Jersey initialization in metter of time and footprint. Jersey initialization is part of start sequence but running in parallel with other staff.

        • What is the cost/risk of fixing the bug?

        This fix has 3 parts:

        1. switch of deployed Jersey application model validation - reduce init duration by 120 ms on my laptop - low risk
        2. reduce number of deployed Jersey providers - reduce init duration by 20 ms and reduce footprint - middle risk
        3. remove non necessary resource auto discovery in Jersey initialization by providing own custom provider - reduce init duration about 100ms - middle risk
        • Is there an impact on documentation or message strings?

        No

        • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

        CLI tests

        • Which is the targeted build of 4.0 for this fix?

        neerest

        • If this an integration of a new version of a component from another project,
          what are the changes that are being brought in? This might be list of
          Jira issues from that project or a list of revision messages.

        N/A

        Show
        martin.mares added a comment - What is the impact on the customer of the bug? Solution improves performance of Jersey initialization in metter of time and footprint. Jersey initialization is part of start sequence but running in parallel with other staff. What is the cost/risk of fixing the bug? This fix has 3 parts: switch of deployed Jersey application model validation - reduce init duration by 120 ms on my laptop - low risk reduce number of deployed Jersey providers - reduce init duration by 20 ms and reduce footprint - middle risk remove non necessary resource auto discovery in Jersey initialization by providing own custom provider - reduce init duration about 100ms - middle risk Is there an impact on documentation or message strings? No Which tests should QA (re)run to verify the fix did not destabilize GlassFish? CLI tests Which is the targeted build of 4.0 for this fix? neerest If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages. N/A
        Hide
        martin.mares added a comment -

        svn 61705

        Show
        martin.mares added a comment - svn 61705

          People

          • Assignee:
            martin.mares
            Reporter:
            Tom Mueller
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: