[ https://jira.jboss.org/jira/browse/JGRP-1133?page=com.atlassian.jira.plug... ] Bela Ban updated JGRP-1133: --------------------------- Fix Version/s: 2.11 (was: 2.10) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JGRP-1133?page=com.atlassian.jira.plugin.sy... ] Bela Ban commented on JGRP-1133: -------------------------------- When a sender P sends a message, it calls NakReceiverWindow.add() which acquires the lock to add the message to the table. When the same message is received, NakReceiverWindow.removeMany() tries to acquire the same lock to remove and deliver the message to P, however, this is done on a different thread (from the thread pool). We need to avoid that blocking of P by the send and deliver method competing for the same lock. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JGRP-1133?page=com.atlassian.jira.plugin.sy... ] Bela Ban commented on JGRP-1133: -------------------------------- We can also replace the CHM for xmit_table with an unlocked HashMap: there is no need for locking, because we already have a RL or WL when we access xmit_table ! Preliminary tests showed perf going from 85MB/sec/node for 4 nodes on the same box going to 92MB/sec/node. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1133?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1133: -------------------------------- Let's take a step back from making NRW concurrent: it is not as simple as it sounds (e.g. add() needs to make sure the seqno to add is >= highest_delivered, but removeMany() also changes highest_delivered ! This requires lockinng of some sort. Also, if we made NRW concurren, we'd also have to make the Retransmitter and timer classes concurrent, and they currently aren't. So the following, less dramatic, changes were made: - NRW already acquires a lock for add(), removeMany() etc. Therefore, we don't need ConcurrentHashMap for xmit_table, and - in a first step - replaced it with an unsynchronized HashMap - In a second step, we replaced HashMap with RetransmitTable. This is a matrix (N rows of M message arrays). If we have many keys (seqnos), then a HashMap deteriorates and when many keys hash to the same bucket, we have to do a linear walk to find an element. The memory overhead of HashMap is also much bigger than for RetransmitTable: every Hashmap.Entry has 4 pointers... - RetransmitTable requires 2 lookups (row and element within the row), whereas HashMap requires more if we have many seqnos in the map (1 to get the bucket from the hash and then N to find the element in the linked list of the bucket). This change made perf go from 132MByte/sec/node on my local box to 148MByte/sec/node ! -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1133?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1133: -------------------------------- Performance on a 4 cluster system is roughly 143MByte/sec/node, so this is good enough for now. Before we continue optimizing NRW, Retransmitter and TimeScheduler(2), we need to see what performance is on a larger cluster, e.g. 30 nodes. I believe, however, that *flow control* [1] might be the more important bottleneck to optimal performance in a large cluster. However, before assuming anything, I need to have access to a larger cluster to actually measure performance and see where the bottleneck is ! [1] https://issues.jboss.org/browse/JGRP-511 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira