[
https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1716:
--------------------------------
So Erik's patch in t_perfhack leaves message batching untouched, but pushes parsing of
non-bundled messages back into the thread pools. I don't object to this, as message
batching is not affected.
Had message batching been pushed back into the pools, I would have objected as we need to
parse the batched messages into different batches (regular, oob-internal and oob) *before*
passing them to the pools.
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.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