Java中的低延迟FIX引擎

总览

Chronicle FIX是我们的Low Latency FIX引擎和Java数据库。

是什么使它与众不同？

是为Java中的超低GC *设计的。
支持字符串和日期时间的方式可以最大程度地减少垃圾和开销。
可自定义为仅包含您期望的字段。
使用通常在二进制解析器和生成器中使用的优化，例如一次读取/写入4或8个字节，以提高效率。
建立在低延迟持久性上，以最大程度地减少日志记录的延迟。
针对低延迟网卡（例如Solarflare）进行了优化。

*超低GC意味着平均每条消息可产生少于一个字节的垃圾
如果您将总垃圾率保持在每小时不足1 GB，则24 GB的Eden可能需要一整天才能填满，并且您不会得到任何次要的GC。每小时产生的速度不到200 MB，您可以在没有GC的情况下运行一周。

但是Java不慢吗？

Java可能比C ++慢，但编写得好Java可以比编写得不好的C ++应用程序快。即仅仅因为某些东西是用C ++编写的，并不能保证它会更快。

正在测试什么？

“解析器测试”乘以解析本机内存中的214字节新顺序单次FIX消息所花费的时间。从SocketChannel读取后，将字段的所有值设置为一个对象。在此测试中，使用Strings设置文本字段，因为这是用Java处理文本数据的更自然的方法。我们有更快的替代方案，例如支持8位字符串。

“生成器测试”乘以从包含字符串和时间戳的数据中生成214字节的New Order Single FIX消息所需的时间，并将其写入本机内存需要多长时间。例如准备写入套接字通道。

注意：字符串和时间戳字段是最昂贵的。有6个字符串和两个时间戳。

在每个测试中，配置为使用SampleTime的JMH运行了10分钟。

该图显示了解析和生成中等大小的FIX消息的等待时间。在解析和生成中， 延迟都小于一微秒，超过了99.9％的时间。

但是较高的百分位数呢？这些看起来不太好。这是因为我正在使用的计算机有一些来自操作系统的噪音，例如我已将其最小化但无法关闭的中断。

较高的延迟是由操作系统引起的。大约每毫秒发生一次中断，持续约2微秒，甚至更罕见的5到7-8微秒的延迟。在更好的服务器上，我仍然希望会有中断，但是中断发生的频率会降低。

下一步是什么？

下一步是将性能测试与Chronicle Journal集成在一起，以查看持久性的影响。 Journal是专门的持久性工具，类似于Chronicle Queue v4，但已针对特定用例进行了调整。在这种情况下，我们需要日记不仅要保留每条消息约150纳秒的时间，而且要比Queue具有更高的一致性。虽然Queue对SSD的写入性能非常好，但大约有1000的写入中有1到100的写入中有1签名延迟，这反映了您对磁盘子系统的选择。即，它直接影响99.9％的延迟。我们可以使用Journal来缓冲此延迟，以显着减少影响。

什么是FIX数据库？

MongoDB是为JSON消息优化的数据库。 Chronicle FIX是为FIX消息优化的数据库。它将数据存储在FIX中，并支持对FIX字段的查询，例如；给我所有有关客户订单ID的消息，或者给我所有在特定时间发送的消息，或者给我在传输时间和接收消息之间最延迟的消息。

Chronicle-FIX是最快的Java代码FIX引擎吗？

我们已经看到了各种FIX引擎引用的许多基准统计数据。尽管基准数字可以使您大致了解处理的数量级，但是几乎可以肯定它们并不能使您确切了解代码的运行速度。

任何人都容易宣称自己拥有最快的FIX引擎并提供一些基准测试数据，但是很难像样地进行比较。基准将始终被优化以适合其所运行的软件。那么，对所有引擎而言，公平的测试到底是什么呢？即使您找到了一个公平的测试，每个人都同意，您必须操纵多少代码才能获得基准测试？用户编写代码时自然会这样做吗？

因此，问题是，Chronicle-FIX最快的FIX引擎是否有些无关紧要。我们当然知道，我们处于正确的球场。最重要的是，Chronicle-FIX已获得咨询许可的方式，以确保针对您的用例进行了优化，我们将与您合作，确保您的代码可以达到我们在基准测试中发布的结果。

如何使用Chronicle FIX？

Chronicle FIX的源代码位于github上，但仅提供给具有许可证的人员。这种想法是，如果您需要一个非常快速的FIX引擎（以亚微秒为单位来衡量您的时间），我们可以帮助您以最佳的方式将其集成到您的软件中。可能是您被现有的数据模型和代码库所束缚，在这种情况下，我们拥有可以大大降低数据转换成本的技术-实际上，我们甚至没有中间数据模型。在一个绿色的项目中，我们可以向您展示如何最好地围绕Chronicle-FIX构建代码。

请通过sales@chronicle.software与我们联系以获取更多信息。

结论

FIX编年史很快。尽管QuickFIX的解析和生成时间不足50微秒，但Chronicle FIX在大多数情况下都可以在2微秒内完成这两项。

我们将提供更多有关持久性如何执行以及数据库如何工作的文档。

翻译自: https://www.javacodegeeks.com/2015/09/low-latency-fix-engine-in-java.html