Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-53648

log throughput decreased by 11%

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Won't Fix
    • 7.1.2
    • 7.1.2
    • eventing
    •  7.1.2-3425

    Attachments

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

      Activity

        Hi Vikas Chaudhary, the only difference from eventing / eventing-ee perspective across these two builds is a switch to Google V8 v10.7.21. This version of V8 libraries had deprecated some functions, so we had to change code to call the replacement functions instead. Apart from such changes to accommodate V8 SDK changes, there are no other Eventing logic change whatsoever.

        As we already have discussed, the upgrade to V8 was expected to have a performance impact due to various checks being done withing V8 to determine use of V8 for attacks of various nature. As such, if the performance difference is due to V8 upgrade, that's just something we need to take as a hit - nothing can be done about it.

        In this case, however, I feel the performance difference while partially will be due to the V8 upgrade, partially is also due to disk being slower. The test-case being identical across the two runs implies almost the same amount of data will be logged and written to disk. If in such a scenario, we are seeing disk-write-queue being larger, and disk-commit-time being more, that likely means that for some reason, the disk has been operating at a slower speed during the second run - could be due to fragmentation, for example.

        Curious - do we run any command to trigger a disk defrag before run?

        srinivasan.raman Srinivasan Raman added a comment - Hi Vikas Chaudhary , the only difference from eventing / eventing-ee perspective across these two builds is a switch to Google V8 v10.7.21. This version of V8 libraries had deprecated some functions, so we had to change code to call the replacement functions instead. Apart from such changes to accommodate V8 SDK changes, there are no other Eventing logic change whatsoever. As we already have discussed, the upgrade to V8 was expected to have a performance impact due to various checks being done withing V8 to determine use of V8 for attacks of various nature. As such, if the performance difference is due to V8 upgrade, that's just something we need to take as a hit - nothing can be done about it. In this case, however, I feel the performance difference while partially will be due to the V8 upgrade, partially is also due to disk being slower. The test-case being identical across the two runs implies almost the same amount of data will be logged and written to disk. If in such a scenario, we are seeing disk-write-queue being larger, and disk-commit-time being more, that likely means that for some reason, the disk has been operating at a slower speed during the second run - could be due to fragmentation, for example. Curious - do we run any command to trigger a disk defrag before run?

        Vikas Chaudhary: I compared the performance numbers of these two builds, focussing specifically on the NOOP function execution and NOOP Timer executions. While there is a degradation, it does not appear to be much - within the tolerance limit. These tests do not perform any disk IO and are likely more representative of the actual V8 overhead across the V8 version involved. Thanks!

        srinivasan.raman Srinivasan Raman added a comment - Vikas Chaudhary : I compared the performance numbers of these two builds, focussing specifically on the NOOP function execution and NOOP Timer executions. While there is a degradation, it does not appear to be much - within the tolerance limit. These tests do not perform any disk IO and are likely more representative of the actual V8 overhead across the V8 version involved. Thanks!

        Srinivasan Raman Yes regression is marginal. We ran good and bad build both on the same disk without defragging. we can close it as expected or keep it open as minor. I will leave that to you. 

        vikas.chaudhary Vikas Chaudhary added a comment - Srinivasan Raman Yes regression is marginal. We ran good and bad build both on the same disk without defragging. we can close it as expected or keep it open as minor. I will leave that to you. 

        Thank you, Vikas Chaudhary...

        In this case, there is actually nothing for us to fix. If this is a V8 issue, we will need to live with it. If this is a disk-slowdown issue, which is what I believe it to be, again, there is nothing for us to fix.

        Question for you:
        Is it possible to include a defrag step as a part of the setup prior to each test or test-suite? That will help eliminate performance issues that may come up due to disk fragmentation, which could skew a given test result.

        Thanks!

        srinivasan.raman Srinivasan Raman added a comment - Thank you, Vikas Chaudhary ... In this case, there is actually nothing for us to fix. If this is a V8 issue, we will need to live with it. If this is a disk-slowdown issue, which is what I believe it to be, again, there is nothing for us to fix. Question for you: Is it possible to include a defrag step as a part of the setup prior to each test or test-suite? That will help eliminate performance issues that may come up due to disk fragmentation, which could skew a given test result. Thanks!

        People

          ankit.prabhu Ankit Prabhu
          vikas.chaudhary Vikas Chaudhary
          Votes:
          0 Vote for this issue
          Watchers:
          5 Start watching this issue

          Dates

            Created:
            Updated:
            Resolved:

            Gerrit Reviews

              There are no open Gerrit changes

              PagerDuty