Page tree
Skip to end of metadata
Go to start of metadata

Overview

All the presented tests are performed using some "reference" hardware and software. It's advised to perform the mentioned benchmarks using target infrastructure and product configuration to get the results that are realistic for the specific use case.

Test Data

FIXEdge Machine

  • 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

Client Machine

  • 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

There are two physical servers interconnected via 10Gb NICs. There are 2 testing scenarios for this setup described below. The FIX message used for testing is:


8=FIX.4.2|9=1|35=D|49=BLP|56=SCHB|34=01|50=30737|52=20000809-20:20:50|11=90001008|1=10030003|21=2|55=TESTA|54=1|38=4000|40=2|59=0|44=30|47=I|60=20000809-18:20:32|10=000|

Where "|" is the FIX SOH separator.

Single Session Echo Scenario

  • FIXEdge has one acceptor session configured.
  • Client application has one initiator session configured.

The overall process looks like:

  1. Client application connects to the FIXEdge instance and sends 200000 FIX 4.2 messages with a rate of 2000 messages per second.
  2. FIXEdge receives the messages and matches it to the same session using business layer logic.
  3. FIXEdge responds to the client application with the same message via the same TCP/IP connection (the same session).

The response time measured by client application is the difference between timestamps:

  • t1 - timestamp taken right before sending message to socket;
  • t2 - timestamp taken right after receiveing the same message from socket (from FIXEdge).

So the round-trip time formula is: RTT=t2-t1 and the measurement unit is microseconds.

The test scenario looks like:

Two Sessions With Conversion Scenario

  • FIXEdge has two acceptor sessions configured.
  • Client application has two initiator sessions configured.

The overall process looks like:

  1. Client application connects to the FIXEdge instance (establishes session №1) and sends 200000 FIX 4.2 messages with a rate of 2000 messages per second.
  2. Client application connects to the FIXEdge instance (establishes session №2) and starts to receive message from another FIXEdge session.
  3. FIXEdge receives the messages sent to it from client application (session №1).
  4. FIXEdge uses business layer logic to route message to another session and convert it from FIX 4.2 to FIX 4.4 protocol.
  5. FIXEdge responds to the client application with the converted message via another TCP/IP connection (session №2).

The round-trip time measured by benchmark is the difference between timestamps (just like in the previous test):

  • t1 - timestamp taken right before sending message to socket;
  • t2 - timestamp taken right after receiveing the same message from socket (from FIXEdge).

The round-trip time formula is: RTT=t2-t1 and the measurement unit is microseconds.

The scenario looks like:

Tests' Configuration


PropertiesValue
Preallocated message buffers1No
Thread Affinity2Yes
Thread pool or Aggressive Mode3Aggressive Mode
Message storage type4persistentMM
Solarflare OpenOnload5Yes
Message validation parameters
MessageMustBeValidated6false
VerifyTagsValuesfalse
IgnoreUnknownFieldstrue
VerifyRepeatingGroupBoundsfalse
CheckVersionOfOutgoingMessagesfalse
  1. Preallocated RAM buffers for FIX messages.
  2. Pin session threads to CPU cores.
  3. Aggressive Mode is when two dedicated threads created for each session - one thread to receive messages and one thread to send messages.
  4. persistentMM is the message storage type represented by memory-mapped local file.
  5. OpenOnload is a Linux alternative networking stack which performs kernel bypass for the application data.
  6. Message validation against FIX dictionaries takes the significant amount of all processing time so it's disabled for testing purposes.

Test Results

Single Session Echo Test

Response time distribution chart (microseconds)
PercentilesMicroseconds
5016.6
9018.7
9924.6
99.555.0
GeneralMicroseconds
Median Response Time16.6
Average Response Time17.2
Standard Deviation6.6



Two Sessions With Conversion Test

Response time distribution chart (microseconds)
PercentilesMicroseconds
5023.5
9026.6
9932.4
99.565.0
GeneralMicroseconds
Median Response Time23.5
Average Response Time24.3
Standard Deviation6.8
  • No labels