最近，我正在研究一種需要復制緩存的產品。 緩存提供程序已經確定-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的博客博客中獲得。