In addition to monitoring the underlying network protocols, Beeks Analytics for Markets will also provide analysis of trading traffic. It does this by decoding the trading protocols, and performing calculations on certain of the decoded fields. It will normalise the messages as well, so that trading messages which are sent over the wire using different messaging protocols are stored consistently in the same format and can be reviewed for comparative performance.

For full details of the types of traffic which Beeks Analytics has decoders for, see the Beeks Analytics Decoder Information document. Even if a trading traffic is missing from that document, as long as it is a public protocol with an available message specification, the Beeks Analytics team will be able to develop a suitable decoder for it.

If a protocol is encrypted, Beeks Analytics for Markets can still monitor network statistics for it by monitoring it as a TCP Gateway. See Monitoring TCP traffic using Beeks Analytics for Markets for details.

Timeseries metrics for Trading traffic

These metrics are available in the same Aggregators as the App-to-wire latency measurements (see below).

Different types of Latency measurement for Trading traffic

Trading traffic differs from Market Data traffic in that two different types of latency calculations are available for Trading traffic:

• App-to-wire latency

• Request/response latency (this is also known as round-trip latency)

These measurements will be performed for traffic to and from a configured Trading Gateway.

All latency measurements over a 10 second period are captured, and the value is recorded each 10 second period. The calculation is made available at multiple percentiles, to assist clients with different volumes of traffic, performance targets and sensitivity to latencies.

Unlike market data latencies (which are measured over a 10 second period, and multiple statistics are recorded each 10 second period), trading latency measurements are recorded for each message.

App-to-wire latency is available to view within the Beeks Portal, per External Group or per Internal Entity. Request/response latency is only available within VMX-Explorer.

App-to-wire latency for Trading traffic

App to wire latency is the time that Beeks Analytics calculates between the SendingTime timestamp written within the message and the time it is observed at the Visibility Point (also known as the Wire time). 

The figure can only be as accurate as the time resolution for the SendingTime field within the message (FIX tag 52 or equivalent field in other trading protocols). Often this is recorded to the nearest millisecond, whereas the wire time is recorded to the nearest microsecond. As a result, figures of hundreds of microsecond can be considered normal.

App to Wire metrics are available as either Rx or Tx direction in the following Aggregators:

App to Wire messages are not persisted, but they can be accessed from the various packet capture download options (as long as the original packet capture has not been overwritten).

Request/response latency for Trading traffic

Request/response latency is also known as round-trip latency. It measures the total time it takes for a system to process a request and deliver a response back to the requester.

 By measuring request/response latency on the wire, you can achieve a number of goals:

• You can measure as close to the client/trading venue as possible. This ensures that you are measuring as close as possible to your true performance.

• Measuring on the wire includes operating system, network card and network latency, which will not be recorded if you only measure using measuring points within your application code.

 Measuring request/response latency on the wire requires correlation, to ensure that the request message and the response message are matched up and considered as part of the same transaction or flow.

As well as the primary request-to-response latency, we also separately record the request-to-acknowledgment latency (where markets provide this, for example FIX Pending New). The request-to-acknowledgment latency can be seen when you drilldown to view a particular item, and will be labelled ‘Ack Response’.

Request/response latency metrics are available in the following Aggregators:

Additional aggregators are also available which provide further breakdowns by Message Type and for internal diagnostic of request/response latency measurement.

Session is a field that is used to record the FIX CompIDs of the FIX session. For non-FIX traffic, this field will be populated with IP addresses.

Dashboards for viewing Trading traffic

Within VMX-Explorer for a Beeks Analytics for Markets deployment, both App-to-Wire and roundtrip latencies can be monitored on the Order Entry Stats by VP dashboard.

In-depth tracking of orders (including a search functionality) is provided on the Order Entry Item Trace dashboard.

Examples of these dashboards and associated navigation advice can be found in the User Guide for VMX-Explorer.

In addition to the above example dashboards, you may find additional dashboards provisioned on your system depending on your specific traffic type. For example, one common dashboard is the Order Entry Stats by Symbol dashboard.