數據要緩存：大小500-5000字節 連貫拓撲建議
生產和測試需要關於Coherence拓撲的建議（分佈式備份）
問題
我們不知道將進行多少次讀取操作，該解決方案將被低響應時間至關重要（超過數據一致性）並取決於每個用例的客戶端使用。緩存將通過以固定頻率輪詢並填充緩存（因爲緩存是數據主服務器，而不是使用緩存的系統）從數據庫更新。
用於調整Coherence的JVM大小的經驗法則是假設1個備份的數據爲堆的1/3：緩存數據爲1/3，備份爲1/3，索引和開銷爲1/3。
上漿最大的困難是沒有好的方法來估計指數大小。你必須嘗試使用真實世界的數據和度量。
JDK 1.6 JVM的經驗法則是以4GB堆開始，所以您需要75個緩存服務器節點。有些人已經獲得了更大的堆（16GB），因此值得嘗試。對於大堆（例如16GB），開銷不應超過1/3，並且數據容量可能超過1/3。隨着堆大於16GB，垃圾收集器調整變得至關重要。
爲獲得最佳性能，每個節點應該有1個核心。
服務器的數量取決於可管理性，容量（內核和內存）和故障的實際限制。例如，即使您的服務器可以處理32個節點，但機器出現故障時您的集羣會發生什麼情況？羣集將是機器安全的（備份不在同一臺機器上），但考慮到將大量數據移至新備份，恢復速度將非常緩慢。另一方面，75臺機器很難管理。
我見過Coherence的延遲爲250微秒（不是毫秒），對於1K對象，包括網絡跳數和備份。因此，您要查找的插入和更新數量應該可以實現。測試多個線程插入/更新，並確保您的測試客戶端不是瓶頸。
一些更多的「經驗法則」：
1）爲了實現高可用性，三個節點是一個很好的最低水平。
2）使用Java 7，可以使用更大的堆（例如27GB）和G1垃圾回收器。
3）對於100GB的數據，使用David的指導原則，您需要總共300GB的堆。在具有128GB內存的服務器上，可以使用3臺物理服務器完成，每臺物理服務器每臺運行4個JVM，每個JVM具有27GB堆（總共約324GB）。
4）索引內存使用情況因數據類型和參數而異。最好使用具有代表性的數據集（包含索引和不包含索引）進行測試，以查看內存使用差異。