java fix_Java中的低延迟FIX引擎

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

java fix