Benchmarks were run against two different versions of FIXEdge Java (1.10.3 and 1.9.0), and the results were compared in order to detect possible regressions.

• Intel(R) Xeon(R) CPU E5-2643 v3 @ 3.40GHz (2 CPU Hyper-Trading Enabled, 24 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

• Intel(R) Xeon(R) CPU E5-2687W 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

• One acceptor session is configured on the FIXEdge Java side.

• One initiator session is configured on the client application side.

The process:

1. The client application connects to the FIXEdge Java instance and sends 1000000 FIX 4.2 messages at a rate of 50000 messages per second.

2. FIXEdge Java receives the messages and matches them to the same session using business layer logic.

3. FIXEdge Java 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 5 times for each FIXEdge Java 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:

The performance of the FIXEdge Java 1.10.3 version is almost the same as the performance of the FIXEdge 1.9.0 version. There is no performance degradation.

Open