FIXEdge 6.15.0 Results
Approach
Benchmarks were run against two different versions of FIXEdge C++ (6.15.0 and 6.14.0), and the results were compared in order to detect possible regressions.
Versions
The following builds were tested:
- FIXEdge C++ 6.14.0.527
- FIXEdge C++ 6.15.0.615
Hardware
FIXEdge Machine
- Intel(R) Xeon(R) CPU E5-2687 v3 @ 3.10GHz (2 CPU Hyper-Trading Enabled, 20 Cores)
- RAM 128 GB, 2133 MHz
- NIC Solarflare Communications SFC9120 (Firmware-version: 4.2.2.1003 rx1 tx1)
- Linux (CentOS 7.0.1406 kernel 3.10.0-123.el7.x86_64)
- SolarFlare driver version: 4.1.0.6734a
Client Machine
- Intel(R) Xeon(R) CPU E5-2687 v3 @ 3.10GHz (2 CPU Hyper-Trading Enabled, 20 Cores)
- RAM 128 GB, 2133 MHz
- NIC Solarflare Communications SFC9120 (Firmware-version: 4.2.2.1003 rx1 tx1)
- Linux (CentOS 7.0.1406 kernel 3.10.0-123.el7.x86_64)
- SolarFlare driver version: 4.1.0.6734a
Benchmarks
Single Session Echo Scenario
- One acceptor session is configured on the FIXEdge C++ side.
- One initiator session is configured on the client application side.
The process:
- The client application connects to the FIXEdge C++ instance and sends 1000000 FIX 4.2 messages with a rate of 50000 messages per second.
- FIXEdge C++ receives the messages and matches them to the same session using business layer logic.
- FIXEdge C++ responds to the client application with the same message via the same TCP/IP connection (the same session).
- The client application collects the response time histogram.
- The process is repeated 3 times for each FIXEdge C++ release version.
The response time measured by the client application is the difference between timestamps:
- t1 - timestamp is taken right before sending a message to the socket
- t2 - timestamp is taken right after receiving the same message from the socket (from FIXEdge)
So the round-trip time formula is: RTT = t2 - t1 and the measurement unit is microseconds.
The test scenario diagram:
Two Sessions With Conversion Scenario
- Two acceptor sessions are configured on the FIXEdge C++ side.
- Two initiator sessions are configured on the client application side.
The process:
- The client application connects to the FIXEdge C++ instance (establishes session â„–1) and sends 1000000 FIX 4.2 messages with a rate of 50000 messages per second.
- The client application connects to the FIXEdge instance (establishes session â„–2) and starts to receive a message from another FIXEdge C++ session.
- FIXEdge C++ receives the messages sent to it from the client application (session â„–1).
- FIXEdge C++ uses Business Layer logic to route the message to another session and converts it from FIX 4.2 to FIX 4.4 protocol.
- FIXEdge C++ responds to the client application with the converted message via another TCP/IP connection (session â„–2).
- The client application collects the response time histogram.
- The process is repeated 3 times for each FIXEdge C++ release version.
The round-trip time measured by benchmark is the difference between timestamps:
- t1 - timestamp is taken right before sending a message to the socket
- t2 - timestamp is taken right after receiving the same message from the socket (from FIXEdge).
The round-trip time formula is: RTT = t2 - t1 and the measurement unit is microseconds.
The test scenario diagram:
Results
The performance of the FIXEdge C++ 6.15.0 release is slightly higher than the performance of the FIXEdge C++ 6.14.0 release. There is no performance degradation.
Single Session Echo Scenario
Two Sessions With Conversion Scenario
Stability
Several series of tests have been performed with different orders of FIXEdge C++ versions during benchmarking. There was no significant spread of the results observed during benchmarking.