[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1722: -------------------------------- I tried the following: # Decryption of the messages of a batch in parallel, using a thread pool. If the decryption cost of a message (assuming similar-sized messages) is 2ms, then decrypting a batch of 10 messages would take 20ms if done sequentially, while it would take ~2ms if done in parallel. Of course, we're assuming here that we have 10 threads available and the cost of context switching is negligible # Use of the asynchronous invocation API to dispatch requests. Every request is handled by a thread from a thread pool (in UPerf) and sending the response as well. The response sending includes encryption of the response, so this cost is amortized by doing this in parallel I tested performance on my local box, my (fast) mac and the lab cluster (8 UPerf instances), and it wasn't better than the sequential algorithm. Possible causes: only half of the messages are actually message batches, the average batch size is small (I verified that they avg is ~ 3.5), and the additional thread context switching caused by the pools diminishes the returns gained by parallelization -- 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