总览
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