ehcache rmi

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

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

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

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

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

此處，y軸是傳輸所需的時(shí)間（以毫秒為單位），x軸是元素的大小。 無(wú)需多說(shuō)。 RMI肯定比JGroups看起來(lái)更好。

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

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

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

參考： 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)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

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

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