在两个节点之间测试了复制。 主要目标是了解增加消息数据大小和消息总数如何影响性能。 另一个目标是找到复制性能真正变差的地方。 后者不是那么容易，因为测试使用的内存量有限，并且空闲内存空间的耗尽可能会导致性能不精简。 以下是用于运行测试的内存大小和软件版本：
- 所有测试使用6GB的堆进行所有执行。
- 测试在EhCache v.2.3.2上执行
- JVM是Sun Java 1.6.0_21
测试本身非常简单。 一个节点将一定数量的具有一定大小的元素放入缓存中，另一节点则读取所有这些元素。 测试输出是读取所有元素所需的时间。 读取第一个元素后，计时器开始计时。
第一个测试为每个迭代创建10000个元素。 变量是消息大小，每次迭代增加两次。 在第一个迭代中，大小为1280字节，在最后一个迭代中为327680字节（320 Kb）。 这意味着具有10000个元素的最终迭代（每个大小为320 Kb）将传输大约3Gb的数据。 测试表明，EhCache可以很好地应对元素大小的增加，并且速度下降与传输数据的大小大致成比例，可以在图形上看到：
此处，y轴是传输所需的时间（以毫秒为单位），x轴是元素的大小。 无需多说。 RMI肯定比JGroups更好。
在秒测试中，变量是元素数，元素的大小保持恒定并等于1280字节。 与之前的测试一样，每次迭代中消息的数量乘以2，而最终迭代中传输的数据量则相同，为3Gb。 下图显示了效果如何：
如上图所示，y轴是一次迭代转移所有元素所需的时间。 X轴是元素的数量。 同样，可以看出RMI是领导者。 我相信帽子JGroups在最新的迭代中大放异彩，这就是为什么它如此糟糕的原因。 这意味着JGroups每个元素具有更多的内存开销。 曾经有一次，谁不相信（我不会;））我的结果并想自己尝试，这里是资源和配置 。
而且，作为结论……好吧，RMI和JGroups的速度都可以接受。 JGroups肯定会消耗更多的内存，这意味着使用它来处理大量数据可能会遇到问题。 另一方面，RMI使用TCP而不是UDP，因为RMI具有大量节点，可能会导致更高的网络负载。 不幸的是，该测试没有以任何方式涵盖后者，其实际影响尚不清楚。
参考： EhCache复制：RMI与JGroups。 从我们的JCG合作伙伴 Stanislav Kobylansky在Stas的博客博客中获得。
翻译自: https://www.javacodegeeks.com/2012/06/ehcache-replication-rmi-vs-jgroups.html
