Numărul 142
Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
Numărul 39
Abonament PDF

Low latency FIX engine in Java

Peter Lawrey
CEO @ Higher Frequency Trading Ltd


Chronicle FIX is our Low Latency FIX engine and database for Java.
What makes it different is that it;

If you keep your total garbage rate to less than 1 GB per hour a 24 GB Eden can take all day to fill up and you don't get any minor GCs.  Produce less than 200 MB/hour and you can run for a week without a GC.

But isn't Java slow?

Java can be slower than C++ but written well Java can be faster than a C++ application not written so well. i.e. Just because something is written in C++ doesn't guarantee it will be faster.

What is being tested?

The "Parser test" times how long it takes to parse a 214 byte New Order Single FIX message in native memory eg. after reading from a SocketChannel and set all the values of the fields into an object.  In this test, the textual fields are set with Strings as this is the more natural way to deal with text data in Java.  We have alternatives which are faster such as support for 8 bit character strings.

The "Generator test" times how long it takes to generate the 214 byte New Order Single FIX message  from data which contain Strings, and timestamps and write it to native memory. e.g. ready to write to a Socket Channel.

Note: Strings and Timestamps fields are the most expensive. There are 6 Strings and two timestamps.

JMH configured to use SampleTime was run for 10 minutes in each test.

This graph shows the latency of parsing and generating a moderately sized FIX message.  In both parsing and generating, the latency was less than a micro-second, more than 99.9% of the time.

But what about the higher percentiles?  These don't look as good.  This is because the machine I am using has some noise from the OS such as interrupts which I have minimised but can't turn off.

The higher delays are caused by the OS. Around once a milli-second there is an interrupt for about 2 micro-seconds and even rarer delays of 5 and 7-8 micro-seconds.  On a better tuned server I will still expect there to be interrupts, but they would occur less often.

What is next?

The next step is to performance test integration with Chronicle Journal to see the impact of persistence.  Journal is a specialised persister which is similar to Chronicle Queue v4 but have been tuned for specific use cases. In this case, we need Journal to not only persist at around 150 nano-seconds per message, but have a higher consistency than Queue.  While Queue performs very well writing to SSD, around 1 in 1000 to 1 in 100 writes will have a signature delay which reflects the choice of disk subsystem you have. i.e. it directly impacts the 99.9% latency.  What we can do with Journal is buffer this delay to significantly reduce the impact.

What is a FIX Database?

MongoDB is a database optimised for JSON messages.  Chronicle FIX is a database optimised for FIX messages. It stores data in FIX and support queries on FIX fields such as; give me all the messages for a client order ID, or give me all the messages sent a specific time, or give me the messages most delayed between transmission time and the time we received them.

Is Chronicle-FIX the fastest FIX engine for Java code?

We've seen a number of benchmark stats quoted for various FIX engines.  Whilst benchmark numbers give you a general insight into the order of magnitude in which you dealing they almost certainly don't give you an exact idea as to how fast your code will run. 

It's easy for anyone to claim that they have the fastest FIX engine with some benchmark figures to back it up but very hard to actually compare like for like.  Benchmarks will always be optimised to suit the software against which it is being run. So what exactly is a fair test for all engines? Even if you find a fair test on which everyone agreed how much do you have to manipulate and tune the code to get the benchmark? Is this something users would naturally do when writing their code?

So the question, is Chronicle-FIX the fastest FIX engine is somewhat irrelevant.  What we certainly know is that we are in the right ball park. Most importantly, the way Chronicle-FIX is licensed with consulting to ensure it is optimised for your use case, we will work with you to make sure that your code can achieve the sort of results we published in the benchmark.

How to use Chronicle FIX?

The source for Chronicle FIX is on github but only available to those with a license. 

The thinking is that if you need a very fast FIX Engine (measuring your times in sub-microseconds) we can help integrate it into your software in the most optimal way for you.  It may be that you are tied into an existing data model and code base in which case we have techniques which vastly reduce the cost of transforming data - in fact we don't even hold an intermediary data model. On a green field project we can show you how to best build your code around Chronicle-FIX.

Please contact us at sales@chronicle.software for any further information


Chronicle FIX is quick.  While QuickFIX struggles to be under 50 micro-seconds to parse + generate, Chronicle FIX is comfortably under two micro-seconds to do both, most of the time.

We will be providing more documentation on how persistence performs and the database works.


NUMĂRUL 142 - Robotics & AI


  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects