ehcache rmi

最近，我正在研究一種需要復(fù)制緩存的產(chǎn)品。 緩存提供程序已經(jīng)確定-EhCache，剩下的就是有關(guān)傳輸?shù)膯栴}。 哪一個是最佳選擇？ 這里的最佳選擇是指性能更好的選擇。 僅在兩個可用傳輸之間進(jìn)行了性能評估-JGroups和RMI，對其他傳輸不予考慮。

在兩個節(jié)點之間測試了復(fù)制。 主要目標(biāo)是了解增加消息數(shù)據(jù)大小和消息總數(shù)如何影響性能。 另一個目標(biāo)是找到復(fù)制性能真正變差的地方。 后者不是那么容易，因為測試使用的內(nèi)存量有限，并且空閑內(nèi)存空間的耗盡可能會導(dǎo)致性能不精簡。 以下是用于運(yùn)行測試的內(nèi)存大小和軟件版本：

• 所有測試使用6GB的堆進(jìn)行所有執(zhí)行。
• 測試在EhCache v.2.3.2上執(zhí)行
• JVM是Sun Java 1.6.0_21

測試本身非常簡單。 一個節(jié)點將一定數(shù)量的具有一定大小的元素放入緩存中，另一節(jié)點則讀取所有這些元素。 測試輸出是讀取所有元素所需的時間。 讀取第一個元素后，計時器開始計時。

第一個測試為每個迭代創(chuàng)建10000個元素。 變量是消息大小，每次迭代增加兩次。 在第一個迭代中，大小為1280字節(jié)，在最后一個迭代中為327680字節(jié)（320 Kb）。 這意味著具有10000個元素的最終迭代（每個大小為320 Kb）將傳輸大約3Gb的數(shù)據(jù)。 測試表明，EhCache可以很好地應(yīng)對元素大小的增加，并且速度下降與傳輸數(shù)據(jù)的大小大致成比例，可以在圖形上看到：

此處，y軸是傳輸所需的時間（以毫秒為單位），x軸是元素的大小。 無需多說。 RMI肯定比JGroups看起來更好。

在秒測試中，變量是元素數(shù)，元素的大小保持恒定并等于1280字節(jié)。 與之前的測試一樣，每次迭代中消息的數(shù)量乘以2，而最終迭代中傳輸?shù)臄?shù)據(jù)量則相同，為3Gb。 下圖顯示了效果如何：

如上圖所示，y軸是一次迭代轉(zhuǎn)移所有元素所需的時間。 X軸是元素的數(shù)量。 同樣，可以看出RMI是領(lǐng)導(dǎo)者。 我相信帽子JGroups在最新的迭代中大放異彩，這就是為什么它如此糟糕的原因。 這意味著JGroups每個元素具有更多的內(nèi)存開銷。 曾經(jīng)有一次，誰不相信（我不會;））我的結(jié)果，想自己嘗試，這里是資源和配置 。

而且，作為結(jié)論……嗯，RMI和JGroups都可以接受。 JGroups肯定會消耗更多的內(nèi)存，這意味著使用JGroups處理大量數(shù)據(jù)可能會遇到問題。 另一方面，RMI使用TCP而不是UDP，因為RMI具有大量節(jié)點，可能會導(dǎo)致更高的網(wǎng)絡(luò)負(fù)載。 不幸的是，該測試沒有以任何方式涵蓋后者，并且真正的影響尚不清楚。

參考： EhCache復(fù)制：RMI與JGroups。 從我們的JCG合作伙伴 Stanislav Kobylansky在Stas的博客博客中獲得。

翻譯自: https://www.javacodegeeks.com/2012/06/ehcache-replication-rmi-vs-jgroups.html

ehcache rmi

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的ehcache rmi_EhCache复制：RMI与JGroups的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。