Derby
  1. Derby
  2. DERBY-2657

Performance regression after check-in of svn 531971

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: 10.3.1.4
    • Component/s: Store
    • Labels:
      None
    • Environment:
      Solaris/Linux, Sun JDK 5 & 6, IBM 1.5
    • Urgency:
      Blocker
    • Bug behavior facts:
      Regression

      Description

      After check-in of svn 531971 on DERBY-2537 it seems like there for
      some loads are a performance regression of about 10-15 percent.

      For more info about this issue see the following mail thread:

      http://www.nabble.com/Performance-regression-after-check-in-on-DERBY-2537-(SVN-531971)-t3651494.html

      1. TestClient2.java
        8 kB
        Olav Sandstaa
      2. d2657.diff
        1.0 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Mike Matrigali added a comment -

          Thanks knut, this is definitely the right fix. I had done the changes to get the dataValueFactory into the class and then forgot to use it rather than looking it up. It is interesting that looking up the factory made such a big difference. I had wondered when I made the change whether it was worth passing the factory down on Xact initialization was worth it - seems it was.

          Show
          Mike Matrigali added a comment - Thanks knut, this is definitely the right fix. I had done the changes to get the dataValueFactory into the class and then forgot to use it rather than looking it up. It is interesting that looking up the factory made such a big difference. I had wondered when I made the change whether it was worth passing the factory down on Xact initialization was worth it - seems it was.
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 546440.

          Show
          Knut Anders Hatlen added a comment - Committed revision 546440.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching a patch (d2657.diff) which makes Xact.getDataValueFactory() return the field value directly instead of going through the Hashtable in BaseMonitor. Derbyall and suites.All ran cleanly.

          Show
          Knut Anders Hatlen added a comment - Attaching a patch (d2657.diff) which makes Xact.getDataValueFactory() return the field value directly instead of going through the Hashtable in BaseMonitor. Derbyall and suites.All ran cleanly.
          Hide
          Knut Anders Hatlen added a comment -

          By the way, the number of allocations of ProtocolKey objects is much smaller on head of trunk, because the DERBY-827 patch started reusing some of them. Still, I think it would be good to have this fixed.

          Show
          Knut Anders Hatlen added a comment - By the way, the number of allocations of ProtocolKey objects is much smaller on head of trunk, because the DERBY-827 patch started reusing some of them. Still, I think it would be good to have this fixed.
          Hide
          Knut Anders Hatlen added a comment -

          I ran Olav's test client against revision 531970 and revision 531971, and used DTrace to monitor object allocations. What jumped out, was that revision 531971 allocated a large number of ProtocolKey objects. It turns out this is caused by Xact.getDataValueFactory() which was introduced in that revision. Instead of returning the value of its dataValueFactory field, it invokes Monitor.findServiceModule() which creates a ProtocolKey object that is used in a Hashtable look-up. When I changed that method so that it just returned dataValueFactory, I didn't see the difference in performance between the two revisions any more.

          Show
          Knut Anders Hatlen added a comment - I ran Olav's test client against revision 531970 and revision 531971, and used DTrace to monitor object allocations. What jumped out, was that revision 531971 allocated a large number of ProtocolKey objects. It turns out this is caused by Xact.getDataValueFactory() which was introduced in that revision. Instead of returning the value of its dataValueFactory field, it invokes Monitor.findServiceModule() which creates a ProtocolKey object that is used in a Hashtable look-up. When I changed that method so that it just returned dataValueFactory, I didn't see the difference in performance between the two revisions any more.
          Hide
          Rick Hillegas added a comment -

          Marking this issue as a blocker for 10.3. We are caught between 2 major focus areas for the 10.3 release: performance improvements and language senstitive ordering. A performance regression is serious enough by itself, but it is particularly serious for a release which is trying to boost Derby performance.

          Show
          Rick Hillegas added a comment - Marking this issue as a blocker for 10.3. We are caught between 2 major focus areas for the 10.3 release: performance improvements and language senstitive ordering. A performance regression is serious enough by itself, but it is particularly serious for a release which is trying to boost Derby performance.
          Hide
          Olav Sandstaa added a comment -

          Test client that can be used to show that there has been a performance regression.

          This test is based on a slightly modified version of the test client found in
          DERBY-1961. The main change is to add a secondary index to
          it that is used for the queries.

          To run this client do:

          1. Create and initialize database:

          java TestClient2 -a initdb -u "jdbc:derby:/tmp/tulldb;create=true"

          2. Run test (which does SELECT * FROM ... WHERE SEC_ID= X) with two
          client threads:

          java TestClient2 -a select -r 60 -c 2 -u "jdbc:derby:/tmp/tulldb"

          Show
          Olav Sandstaa added a comment - Test client that can be used to show that there has been a performance regression. This test is based on a slightly modified version of the test client found in DERBY-1961 . The main change is to add a secondary index to it that is used for the queries. To run this client do: 1. Create and initialize database: java TestClient2 -a initdb -u "jdbc:derby:/tmp/tulldb;create=true" 2. Run test (which does SELECT * FROM ... WHERE SEC_ID= X) with two client threads: java TestClient2 -a select -r 60 -c 2 -u "jdbc:derby:/tmp/tulldb"

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Olav Sandstaa
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development