FIXEdge 6.15.0 Results

Owned by Yaroslav Melyn
May 08, 2023
3 min read

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:

  1. The client application connects to the FIXEdge C++ instance and sends 1000000 FIX 4.2 messages with a rate of 50000 messages per second.
  2. FIXEdge C++ receives the messages and matches them to the same session using business layer logic.
  3. FIXEdge C++ responds to the client application with the same message via the same TCP/IP connection (the same session).
  4. The client application collects the response time histogram.
  5. 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:

  1. 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.
  2. The client application connects to the FIXEdge instance (establishes session №2) and starts to receive a message from another FIXEdge C++ session.
  3. FIXEdge C++ receives the messages sent to it from the client application (session №1).
  4. 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.
  5. FIXEdge C++ responds to the client application with the converted message via another TCP/IP connection (session №2).
  6. The client application collects the response time histogram.
  7. 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.