佛山网站建设费用预算,长春绿园网站建设,酒店网站建设目标,营销型网站建设价值最近#xff0c;我正在研究一种需要复制缓存的产品。 缓存提供程序已经确定-EhCache#xff0c;剩下的就是有关传输的问题。 哪一个是最佳选择#xff1f; 这里的最佳选择是指性能更好的选择。 仅在两个可用传输之间进行了性能评估-JGroups和RMI#xff0c;对其他传输不予考… 最近我正在研究一种需要复制缓存的产品。 缓存提供程序已经确定-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肯定会消耗更多的内存这意味着使用它来处理大量数据可能会遇到问题。 另一方面RMI使用TCP而不是UDP因为RMI具有大量节点可能会导致更高的网络负载。 不幸的是该测试没有以任何方式涵盖后者其实际影响尚不清楚。 参考 EhCache复制RMI与JGroups。 从我们的JCG合作伙伴 Stanislav Kobylansky在Stas的博客博客中获得。 翻译自: https://www.javacodegeeks.com/2012/06/ehcache-replication-rmi-vs-jgroups.html
