The following benchmarks measure VMX-Analysis performance:

  • VMX-Analysis events per second, with simple request/response correlation (not persisted)

  • VMX-Analysis events per second, with simple request/response correlation (persisted to database)

The benchmarks were produced from unique tests, not concurrent tests with the other tests. For high volume deployments where both capture and VMX-Analysis performance are important, Beeks typically recommends that VMX-Analysis may need to run on separate hardware from VMX-Capture to achieve higher performance. This is not necessary for more typical deployments.

A general guideline for sizing deployments where VMX-Analysis and VMX-Capture co-exist on the same hardware is that VMX-Analysis needs to have 16 cores of CPU to run, and if you need higher Capture Probe performance (or Stack Probe performance for reading captures from disk), then you should ensure that VMX-Analysis and VMX-Capture files are configured on separate disk volumes.

What statistics are available to me with VMX-Analysis performance?

As per the Stack Probe performance for FIX messaging but also including:

  • Request/response latency for Trading traffic (including both request-to-response and request-to-acknowledgment)

  • Breakdown of latency or other metrics by Message Type, by Symbol, or by other message attributes.

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’.

What information is available to me without persistence?

With no persistence, you will get the measurements recorded as statistics, but the orders will not be committed to the relational database so you will not, for example, be able to filter orders by latency or search by order attributes.

The orders will still be saved in packet captures though - so, as long as you still have the packet capture stored, you can use the statistics (graphs etc) to identify the time period where a particular high or low latency occurred, and you can then retrospectively interrogate these packet captures. See the Prism section of the Analytics Concepts Guide for more information.

With the addition of persistence, you will be able to:

  • Filter orders by latency

  • Search by order attributes

  • View how different items in the transaction relate to each other, and study the different timings of the different parts of the transaction