[
https://issues.jboss.org/browse/ISPN-1918?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-1918:
------------------------------------
I also re-ran the state transfer simulation and these are the maximum latencies when
transferring a 4.5MB state from each node to a single joiner:
|| || UNICAST version|| FC || RSVP || 2|| 3|| 4||
|jgroups-udp.xml| 1| n| n| 55| 946| 3344|
| | | y| n| 76| 381| 952|
|jgroups-udp-unicast2.xml| 2| n| n| N/A| N/A| N/A|
| | | n| y| 77| 955| 5016|
| | | y| n| 64| 5023| 10005|
| | | y| y| 78| 854| 1354|
UNICAST+FC is clearly the best, but state transfers happen seldom enough that an extra
500ms (as we see for UNICAST2+FC+RSVP) should not make a big impact.
Node that we had configured {{<RSVP resend_interval="500"/>}} - if we set
the resend interval lower the UNICAST2+FC+RSVP would get even closer to UNICAST.
Benchmark UNICAST vs UNICAST2 vs NAKACK2 with JGroups 3.0.x
-----------------------------------------------------------
Key: ISPN-1918
URL:
https://issues.jboss.org/browse/ISPN-1918
Project: Infinispan
Issue Type: Task
Components: RPC
Affects Versions: 5.1.2.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Labels: jgroups_tuning
Fix For: 5.1.3.CR1, 5.1.3.FINAL
Recent changes seem to have brought performance a bit down, so we need to check whether
this is caused by reverting to UNICAST instead of UNICAST2 (ISPN-1892).
Performance has decreased most in the 2-node scenario, where we were actually sending
multicasts instead of unicasts. So we need to check whether there is a performance
difference between UNICAST2 and NAKACK2 as well.
If we find UNICAST2 to perform better, we can proceed with ISPN-1879 on the 5.1.x branch
as well as on the master branch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira