ehcache rmi_EhCache复制：RMI与JGroups

ehcache rmi

最近，我正在研究一种需要复制缓存的产品。缓存提供程序已经确定-EhCache，剩下的就是有关传输的问题。哪一个是最佳选择？这里的最佳选择是指性能更好的选择。仅在两个可用传输之间进行了性能评估-JGroups和RMI，对其他传输不予考虑。

在两个节点之间测试了复制。主要目标是了解增加消息数据大小和消息总数如何影响性能。另一个目标是找到复制性能真正变差的地方。后者不是那么容易，因为测试使用的内存量有限，并且空闲内存空间的耗尽可能会导致性能不精简。以下是用于运行测试的内存大小和软件版本：

所有测试使用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肯定会消耗更多的内存，这意味着使用JGroups处理大量数据可能会遇到问题。另一方面，RMI使用TCP而不是UDP，因为RMI具有大量节点，可能会导致更高的网络负载。不幸的是，该测试没有以任何方式涵盖后者，并且真正的影响尚不清楚。

参考： EhCache复制：RMI与JGroups。从我们的JCG合作伙伴 Stanislav Kobylansky在Stas的博客博客中获得。