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.