Benchmarking FIX Engines: Measure Network and Parsing Together
Summary
The document discusses how to evaluate FIX engine throughput and why parser speed alone can be misleading. It reports encoding and decoding timings for two processor setups, then points out that converting those timings directly into messages per second assumes network I/O takes no time. Since network reading and writing can dominate parser costs, the suggested benchmark measures receiving bytes and decoding them together.
The cited combined read-and-parse benchmark reports 250,000 messages per second. The answer also recommends comparing engines with reproducible benchmark code where available. These figures are tied to specific hardware and a particular engine, and the response discloses that its author helped develop that engine. Message size, network conditions, FIX session behavior, and workload mix can all change results, so the examples are context rather than universal performance targets.
Key ideas
- Parser-only timing does not capture the network cost of a FIX engine.
- Benchmark encoding and decoding separately to identify parser performance.
- Measure network input together with parsing for a more realistic throughput estimate.
- Reported performance depends on hardware, engine implementation, and workload.
- Reproducible benchmark code can support comparisons across FIX engines.
Tags
Full text
# What would be considered a good/competitive throughput for a FIX engine? # What would be considered a good/competitive throughput for a FIX engine? I am writing my own FIX engine and I am in the process of running some benchmarks. I am not sure whether my results are good or bad. Can someone with experience in the area provide me with some benchmark throughput numbers? How many FIX messages should my client be able to process per second? ## Answer by rdalmeida (score 4) https://quant.stackexchange.com/a/15138 We believe that the FIX parser (encoder/decoder) is the easiest part of a FIX engine to optimize. The bottleneck is usually the network I/O because you can't do any encoding/decoding before you receive/send the bytes from/to the network. Below are the CoralFIX numbers we measured using an Intel Xeon 2.0GHz machine: In terms of encoding (from `FixMessage` to `ByteBuffer`), we can encode 5 million messages without producing any garbage in 1.408 micros on average per message. In terms of decoding (from `ByteBuffer` to `FixMessage`), we can decode 5 million messages without producing any garbage in 1.997 micros on average per message. Now the same numbers using an Intel i7 3.5GHz machine overclocked to 4.5GHz: From `FixMessage` to `ByteBuffer` - 794 nanoseconds on average per message. From `ByteBuffer` to `FixMessage` - 1.1 micros on average per message. If you want a rough estimate for throughput you can do the math: > Throughput = 1 second in nanos / (time above in nanos) = 1,000,000,000 / (time above in nanos) But that will give you unrealistic numbers (> 1 million mps) because it is assuming that your network I/O time is zero. It does not help to save nanoseconds for parsing when you will be spending microseconds with network I/O. Therefore we like to measure the combined time of reading the bytes from the network plus parsing the bytes into a `FixMessage`. We have done this benchmark here, and the number was 250k fix messages per second read from the network and parsed. Disclaimer: I am one of the developers of CoralFIX. ## Answer by user508 (score 2) https://quant.stackexchange.com/a/15133 Fix8 has some benchmark results on their website. They provide the code, so you can run your own benchmarks with your FIX engine against either Quickfix or Fix8.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.