FIXEdge 6.14.0 Results

Owned by Yaroslav Melyn
Last updated: May 09, 2023

Approach

Benchmarks were run against two different versions of FIXEdge C++ (6.14.0 and 6.13.0), and the results were compared in order to detect possible regressions.

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

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 at 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.14.0 version is the same as the performance of the previous FIXEdge 6.13.0 version. 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.