兵马俑性能和技巧

Question

在大约一个月前发现 Terracotta 后，我才刚刚开始学习如何使用它。这是一项非常酷的技术。

基本上我正在尝试做的事情：

我的根（记录系统）是一个 ConcurrentHashMap。

主要的 Instrumented Class 是一个“JavaBean”，它有 30 个左右的字段，我希望它们存在于 HashMap 中。

Hashmap 中将存在大约 20000 个这些 JavaBean。

每个 bean 有（至少）5 个字段，每 5 秒更新一次。

（我之所以使用 Terracotta 是因为这些 JavaBean 需要跨 JVM 和节点进行访问。）

任何比我更有 TC 经验的人有什么建议吗？性能是关键。

还有其他类似应用的例子吗？

Answer 1

您可能会发现在一个锁定范围内批处理多个更改会执行得更好。每个同步块/方法形成一个写事务（假设您使用写锁），必须发送到服务器（并可能返回到其他节点）。通过更改一堆字段，可能是在一个锁下的一堆对象上，您可以减少创建事务的开销。至少可以玩的东西。

分区也是提高性能的关键方法。更改只需要发送到实际使用对象的节点。因此，如果您可以划分哪些节点通常会接触特定对象，从而减少必须在集群中发送的更改数量，从而提高性能。

unnutz 关于使用 CHM 或 CSM 的建议很好。 CHM 允许更大的并发性（因为每个内部段都可以被锁定并同时使用）——确保也尝试使用更大的段数。 CSM 每个条目实际上有一个锁，因此在 N 大小的表中实际上有 N 个分区。这可以大大减少锁争用（以管理更多内部锁对象为代价）。 CSM 即将发生的变化将使锁定管理成本大大降低。

一般我们发现一个好的策略是：

1. 构建性能测试（应该是多线程和多节点的，并且与您的应用（或您的实际应用！）类似！）
2. 调整对象 - 查看开发控制台中的集群对象图以查找根本不需要集群的对象 - 有时这种情况会意外发生（删除或使用瞬态字段切割集群）。有时，您可能会聚集一个很长的日期。微小的变化，但这是每个地图条目一个对象，这可能会有所作为。
3. 调整锁 - 使用开发控制台中的锁分析器查找热锁或太窄或太宽的锁。集群统计数据记录器也可以帮助查看交易规模。
4. 调整 GC 和 DGC - 调整 JVM 垃圾收集，然后通过打开更改年轻代 gc 的频率调整 Terracotta 分布式 GC。
5. 调整 TC 服务器 - 在这里进行许多非常详细的调整，但通常在调整上述内容之前不值得。

您也可以在 Terracotta forums 上提问 - 所有工程、现场工程、产品管理人员都观看这些内容并在那里回答。

Answer 2

首先，我建议你在他们的论坛上也提出这个问题。

其次，实际上，集群在 Terracotta 上的应用程序的性能将取决于发生的写入事务的数量。因此，您可以考虑使用 ConcurrentStringMap（如果您的键是字符串）或 ConcurrentHashMap。请注意，从性能角度来看，CSM 比 CHM 好得多。

毕竟，POJO 是延迟加载的。这意味着每个属性都是按需加载的。

希望对您有所帮助。

干杯