Performance 使用Scala/Akka在JVM中进行高频交易

让我们设想一个假设的Java HFT系统，需要（非常）低的延迟，有许多短生命的小对象，这多少是由于不可变性（Scala？），每秒数千个连接，以及在事件驱动体系结构（akka和amqp？）中传递的大量消息

对于那些专家来说，JVM7的最佳调优（假设）是什么？什么类型的代码会让它快乐？Scala和Akka是否准备好使用这种系统

---

注意：有一些类似的问题，比如这个，但我还没有找到一个涉及Scala的问题（它在JVM中有自己独特的足迹）。

在我的笔记本电脑上，Akka 2.3.7参与者之间ping消息的平均延迟是，它远小于JVM上GC暂停所预期的延迟

Akka和其他参与者在Intel Core i7-2640M上的代码（包括JVM选项）和测试结果

---

另外，你可以在Dmitry Vyukov和Martin Thompson的书中找到很多关于低延迟计算的原理和技巧

在Java中实现非常好的性能是可能的。然而，这个问题需要更加具体，以提供可信的答案。延迟的主要来源将来自以下非详尽列表：

您创建了多少垃圾以及GC收集和处理垃圾的工作 推广它。以我的经验来看，一成不变的设计不适合我 低延迟。GC调优需要成为一个重点

预热JVM，以便加载类并且JIT有时间 做它的工作

将您的算法设计为O（1）或至少O（log2n），并且 证明这一点的性能测试

您的设计需要无锁，并遵循“”

需要付出巨大的努力来理解整体 堆叠并在使用中表现出机械的同情

将算法和数据结构设计为缓存友好型。 目前缓存未命中是最大的成本。这是密切相关的 与流程关联相关，如果设置不正确，可能会导致 以及严重的缓存污染。这将涉及到对操作系统的同情，甚至在某些情况下对一些JNI代码的同情

确保有足够的内核，以便任何需要 run有一个内核，无需等待

---

我最近在博客上写了一篇关于这种练习的文章。

你可能会发现，使用环形缓冲区进行消息传递将超过使用Akka所能做到的。人们在用于金融应用的JVM上使用的主要环形缓冲区实现是一个称为Disruptor的实现，它经过了仔细的调整，以提高效率（两种大小的能力）、JVM（没有GC，没有锁）和现代CPU（没有缓存线的错误共享）

---

从Scala的角度来看，这里是一个介绍，最后一张幻灯片上有指向原始LMAX内容的链接。

另外，问题是JVM是否是正确的选择？也许C++会提供更可预测的延迟。我听说斯卡拉曾经用C代码来做实际的HFT，但是我不能回忆任何细节。由于链接问题中提到的1-3秒对于HFT来说太长了，我认为在JVM上编写HFT软件不是一个好主意。问题是一般性的。我只是不理解为什么人们尝试使用垃圾收集语言来降低延迟。为什么C不更常用呢？你可能在一秒钟内有数千条消息进出，但在HFT系统中肯定不会有数千条连接。非常有趣！谢谢分享。仅供参考，改进现在已经解决，并且是JDK 7更新版本的一部分。注意：平均延迟实际上只是吞吐量的倒数。您想知道延迟的分布是基于消息应该发送的时间，而不是消息发送的时间。i、 e.您希望避免协调遗漏。我删除了typesafe博客上对吞吐量测试的引用，以避免误解1/latency=吞吐量。