数据要缓存：大小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）索引内存使用情况因数据类型和参数而异。最好使用具有代表性的数据集（包含索引和不包含索引）进行测试，以查看内存使用差异。