Table of Contents
Approach
Benchmarks were run against two different versions of FIXEdge versions C++ (FIXEdge 6.14.0 and FIXEdge 6.13.0) to compare results. FIXEdge 6.14.0 version was also tested with enabled and disabled queueing to detect the feature's performance influence.
Versions
In , and the results were compared in order to detect possible regressions FIXEdge 6.14.0 and the previous FIXEdge 6.13.0 .
Versions
The following builds were tested:
- FIXEdge C++ 6.13.0.500
- FIXEdge C++ 6.14.0.527
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
...
Single Session Echo Scenario
A single session was defined. FIXEdge was configured to send every incoming message back to the sender. The sender posted messages at an approximately constant rate and collected the response time histogram. The response time is by definition the time interval between sending a message and receiving the reply.
The outputs of the benchmark are:
- the overall summary of each run.
- the response time of each message measured in nanoseconds.
- the histogram of the response times.
- the plot of the histogram of the response time.
- configuration and log files of FIXEdge and the sender app.
Benchmark's parameters:
Message count: 1000000
Message rate: 50000 messages per second
Two Sessions With Conversion Scenario
Two sessions were defined: the first one used FIX version 4.2, and the second used FIX 4.4. FIXEdge converted every message received in the 1st session to FIX 4.4 and sent it to the 2nd session. The sender connected to both sessions posted messages to the 1st session at an approximately constant rate and received replies in the second session. The quantity measured by this benchmark is the response time histogram. The response time is by definition the time interval between sending an N-th message and receiving an N-th reply.
Benchmark's parameters:
Message count: 1000000
Message rate: 50000 messages per second
Results
...
- 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 at 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:
Drawio border false diagramName Benchmarks FE - 1 simpleViewer false width 600 links auto tbstyle hidden diagramDisplayName lbox false diagramWidth 540 revision 1
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:
Drawio border false diagramName Benchmarks FE - 2 simpleViewer false width links auto tbstyle hidden diagramDisplayName lbox false diagramWidth 730 revision 1
Results
The performance of the FIXEdge C++ 6.14.0 version is the same as the performance of the previous FIXEdge 6.13.0 version. So there There is no performance degradation within the release..
Single Session Echo Scenario
Two Sessions With Conversion Scenario
Single Session Echo Scenario
Stability
Several series of tests have been performed with different orders of FIXEdge C++ versions during the benchmarkbenchmarking. There was no significant spread of the results observed during benchmark runsbenchmarking.