[jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823320#comment-12823320 ] 

Bela Ban edited comment on JGRP-1716 at 10/19/13 12:27 PM:
-----------------------------------------------------------

I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | *26'852* | *11'960* |
| 34-udp-bundle-getall | 27'765 | 9'175 | *34'631* | *15'088* |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | *15'640* | *4'905* |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | *22'980* | *6'526* |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

h5. Findings
* The results for 3.4 are *all* better in the new run than the old 3.4 run
* The non-bundled result in the new 3.4 run are 50% better than the corresponding 3.2 run and 50% worse !
* All of the bundled results in the new 3.4 run are better than the non-bundled results in either the old 3.4 or the 3.2 run !
** --> If the latter is confirmed by Radim in his own tests, then we should look into abandoning using the DONT_BUNDLE flag. Note that JGRP-1717 is about investigating why using DONT_BUNDLE is faster than not, but the results above indicate the contrary.
                
      was (Author: belaban):
    I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | *26'852* | *11'960* |
| 34-udp-bundle-getall | 27'765 | 9'175 | *34'631* | *15'088* |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | *15'640* | *4'905* |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | *22'980* | *6'526* |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

h5. Findings
* The results for 3.4 are *all* better in the new run than the old 3.4 run
* The non-bundled result in the new 3.4 run are 50% better than the corresponding 3.2 run and 50% worse !
* All of the bundled results in the new 3.4 run are better than the non-bundled results in either the old 3.4 or the 3.2 run !
                  
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira