← Back to article listing


April 12, 2023
Share this

The OnixS FIX Engine SDKs include reference implementation source code samples that are an aid for developers to quickly get familiar with, and then adapt to the target contexts.

 

One of those samples includes performance benchmarks.

 

We’re often asked, “what is your performance like?”

 

The best answer is to measure it yourself using the included reference implementation benchmark samples on the target platform(s).

 

That remains the recommendation, but these are some performance comparison numbers that we are commonly asked about so we’re sharing them here. 

 

Hardware

 

Intel(R) Core(TM) CPU i7-7700K @ 4.20GHz, 32 GB RAM

 

Software

 

Ubuntu 20.04 gcc 9.4.0

OnixS FIX Engine for .NET Core / .NET 6 v 1.9.0
QuickFIXn.Core v 1.10.0

 

Throughput (msg/sec)

Message length: 131 bytes.

 

Mode 

OnixS 

QuickFIXn

% OnixS faster

Send side

377,118

30,044

13x

Receive side

376,499

30,314

12x

 

Latency (microseconds)

Message length: 144 bytes.

 

Mode

OnixS

QuickFIXn

% OnixS faster

Internal send min

0.632

2.727

4.3x

Internal send median

0.755

3.424

4.5x

Internal send 99%

0.887

4.051

4.6x

Overall send min

2.915

80.798

27.7x

Overall send median

3.189

87.259

27.3x

Overall send 99%

3.833

153.346

40x

RTT/2 min

4.410

50.124

11.3x

RTT/2 median

5.722

57.879

10.1x

RTT/2 99%

6.540

74.791

11.4x

 
 

Parsing (msg/sec)

 

Message size

OnixS

QuickFIXn

% OnixS faster 

Small (106 bytes)

2,651,736

465,146

5.7x

 

Notes:

  • There is no ability to measure internal receive latency in QuickFIXn because there is no onReceivedBytes analog as in the OnixS FIX Engine.

  • The QuickFIXn internal send latency, unlike the OnixS FIX Engine internal send latency, does not include the outgoing message serialization and session storage latencies because the toApp callback is called before these processes.

Is your FIX Engine specifically designed for ultra-low latency, high-frequency trading infrastructure?