Bug 965220
| Summary: | Regression in library mode PUT performance from JDG 6.1 to Infinispan 5.3 beta 2 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Data Grid 6 | Reporter: | Alan Field <afield> | ||||
| Component: | Performance | Assignee: | Tristan Tarrant <ttarrant> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Martin Gencur <mgencur> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.1.0 | CC: | afield, jdg-bugs, mmarkus, myarboro | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-07-03 13:49:11 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Alan Field
2013-05-20 18:02:30 UTC
I just want to update this report with the correct interpretation of the durations in the log file: 12:23:57,818 INFO [org.radargun.stages.LoadFileStage] (main) Received responses from all 8 slaves. Durations [0:31.83 seconds, 1:31.96 seconds, 2:31.9 seconds, 3:32.06 seconds, 4:44.53 seconds, 5:44.37 seconds, 6:44.5 seconds, 7:31.83 seconds] The number before the ":" is the node index, and is not part of the duration. The duration on node 0 was 31.83 seconds. The duration on node 1 was 31.96 seconds, etc. This is the source for the LoadFileStage as well: https://github.com/radargun/radargun/blob/master/framework/src/main/java/org/radargun/stages/LoadFileStage.java This regression was caused by a stale value in the JGroups configuration file. The previous version of the file had UDP.bundler_type="old". In the new version of the file, the value is UDP.bundler_type="new". Here are the results with the new configuration file in place:
17:42:51,749 DEBUG [org.radargun.Master] (main) Starting 'LoadFileStage' on 8 slave nodes. Details: LoadFile {bucket=null, exitBenchmarkOnSlaveFailure=false, filePath=/qa/services/hudson/static_build_env/jdg/data/william-shakespeare-100MB.txt, printWriteStatistics=false, runOnAllSlaves=false, slaves=null, useSmartClassLoading=true, valueSize=1024 }
17:42:51,759 INFO [org.radargun.Slave] (pool-1-thread-1) Executing stage: LoadFile {bucket=null, exitBenchmarkOnSlaveFailure=false, filePath=/qa/services/hudson/static_build_env/jdg/data/william-shakespeare-100MB.txt, printWriteStatistics=false, runOnAllSlaves=false, slaves=null, useSmartClassLoading=true, valueSize=1024 }
17:42:51,761 INFO [org.radargun.stages.LoadFileStage] (pool-1-thread-1) Writing 1024 bytes to cache key: 7-7168 at position 8192
17:43:09,626 INFO [org.radargun.stages.LoadFileStage] (pool-1-thread-1) Writing 1024 bytes to cache key: 7-40967168 at position 40968192
17:43:17,487 INFO [org.radargun.stages.LoadFileStage] (pool-1-thread-1) Writing 1024 bytes to cache key: 7-81927168 at position 81928192
17:43:20,856 INFO [org.radargun.Slave] (pool-1-thread-1) Finished stage: LoadFile {bucket=null, exitBenchmarkOnSlaveFailure=false, filePath=/qa/services/hudson/static_build_env/jdg/data/william-shakespeare-100MB.txt, printWriteStatistics=false, runOnAllSlaves=false, slaves=null, useSmartClassLoading=true, valueSize=1024 }
17:43:20,857 INFO [org.radargun.Slave] (main) Ack successfully sent to the master
17:43:20,985 INFO [org.radargun.stages.LoadFileStage] (main) Received responses from all 8 slaves. Durations [0 = 29.16 seconds, 1 = 29.1 seconds, 2 = 29.2 seconds, 3 = 29.09 seconds, 4 = 29.13 seconds, 5 = 29.09 seconds, 6 = 29.22 seconds, 7 = 29.09 seconds]
17:43:20,987 INFO [org.radargun.stages.LoadFileStage] (main) --------------------
17:43:20,987 INFO [org.radargun.stages.LoadFileStage] (main) Size of file '/qa/services/hudson/static_build_env/jdg/data/william-shakespeare-100MB.txt' is 100623474 bytes
17:43:20,987 INFO [org.radargun.stages.LoadFileStage] (main) Value size is '1024' which will produce 98266 keys
17:43:20,987 INFO [org.radargun.stages.LoadFileStage] (main) Slave 0 wrote 12284 values to the cache with a total size of 12578816 bytes
17:43:20,988 INFO [org.radargun.stages.LoadFileStage] (main) Slave 1 wrote 12284 values to the cache with a total size of 12577906 bytes
17:43:20,988 INFO [org.radargun.stages.LoadFileStage] (main) Slave 2 wrote 12283 values to the cache with a total size of 12577792 bytes
17:43:20,988 INFO [org.radargun.stages.LoadFileStage] (main) Slave 3 wrote 12283 values to the cache with a total size of 12577792 bytes
17:43:20,988 INFO [org.radargun.stages.LoadFileStage] (main) Slave 4 wrote 12283 values to the cache with a total size of 12577792 bytes
17:43:20,989 INFO [org.radargun.stages.LoadFileStage] (main) Slave 5 wrote 12283 values to the cache with a total size of 12577792 bytes
17:43:20,989 INFO [org.radargun.stages.LoadFileStage] (main) Slave 6 wrote 12283 values to the cache with a total size of 12577792 bytes
17:43:20,989 INFO [org.radargun.stages.LoadFileStage] (main) Slave 7 wrote 12283 values to the cache with a total size of 12577792 bytes
17:43:20,989 INFO [org.radargun.stages.LoadFileStage] (main) --------------------
These values are consistent with JDG 6.1. Maybe JGroups 3.3.x should print a warning message when UDP.bundler_type="old" is being used?
Pedro Ruivo <pedroruivo2> made a comment on jira ISPN-3126 In any case, I've sent an email to ispn-dev warning about the use of the new bundler. Mircea Markus <mmarkus> made a comment on jira ISPN-3126 Can you please close it once you confirmed that this is not a problem? The performance degradation is not a bug, but JGroups should warn that the old bundler is enabled. I'll enter a new JIRA for that. Martin Gencur <mgencur> updated the status of jira ISPN-3126 to Resolved Martin Gencur <mgencur> made a comment on jira ISPN-3126 This is not a bug. The performance regression was caused by incorrect JGroups settings. |