Research
How we measure exchange latency, and what the two numbers mean
The Latency Monitor shows a connect time and a request time for every venue. Here is exactly how each is produced, why they are kept apart, and what you should not read into them.
Research-Artikel werden auf Englisch veröffentlicht.
Every minute, a small program on our server opens a connection to the public API host of each venue we track, sends a handful of the lightest requests that venue offers, and writes down two numbers. This note is the full description of that procedure, so that anyone can reproduce it and so that nobody over-interprets it.
The two numbers
Connect is the time from the first TCP packet to a completed TLS handshake. It is what a connector pays every time it has to open a socket: at start-up, after a venue drops the session, after a network blip. It is dominated by round trips: a TCP handshake is one, a TLS 1.3 handshake is one more, TLS 1.2 is two. A venue fronted by a content delivery network often shows a short connect time, because the handshake is completed by an edge node near our server rather than by the venue’s own gateway.
Request is the time from sending a complete HTTP request on an already open connection to receiving the complete response. We send the request four times on the same connection and keep the median of the last three. The first request is discarded on purpose: on several venues it is measurably slower, because something on the far side is being set up for the new session, and a running connector almost never sees that cost.
The two are reported separately because they answer different questions. Connect tells you what a reconnect costs and how far away the TLS endpoint is. Request tells you how the venue’s gateway behaves for a client that is already connected, which is the steady state of any trading system.
Which endpoints
We use the cheapest unauthenticated call each venue exposes, almost always “server time” or “ping”. The host and path for every venue are listed on the Latency Monitor page. These calls carry no market data and no account data; they exist so that clients can check connectivity and clock offset, which is exactly what we use them for.
Market-data calls would be heavier and would mix the venue’s data-serving path into the number. Authenticated calls would require keys and would measure a different path again, the one behind signature checks and account lookups. Both are interesting; neither is what this monitor measures.
Cadence and footprint
One run per minute, all venues in parallel, four requests per venue per run. That is under one request per second across all sixteen venues combined, with a user agent that names the probe and links to the product page. If a venue returns an error status, the run records the status and stops sending to that venue until the next minute.
Samples are kept for ninety days. The public board shows the latest sample; the venue table shows the 24-hour average and the share of runs in which the venue answered successfully. Account holders can pull the raw series through the API.
Where the probe sits
The probe runs from our server in a European data centre, the region named on the board. It is not in any exchange’s co-location facility and it is not in the cloud region where any matching engine lives. The numbers therefore describe a venue’s public gateway as seen from Europe, over the public internet, through whatever CDN or load balancer the venue puts in front of it.
That is useful for three things: noticing when a venue degrades, noticing when it stops answering, and comparing venues’ gateways from one fixed vantage point over time. It is useless for a fourth thing people sometimes try to use it for: estimating the latency of your own trading system. Your number depends on where your server is, on authenticated endpoints, and on the venue’s internal path from gateway to matching engine, none of which this probe sees. If you want your own number, run the same procedure from your own machine; the method above is all you need.
What can go wrong with the method, and what we do about it
- A venue’s CDN hides the origin. The connect number then describes the distance to an edge node, not to the venue. We say so on the venue table rather than pretending otherwise.
- The venue rate-limits or blocks probes from data-centre addresses. Then the run records an HTTP error and the uptime figure drops, which is a real finding about that venue for anyone hosting in a similar place, but not evidence of an outage for everyone. We annotate venues where this is known to happen.
- Our own server has a bad minute. All venues would degrade together; the status page shows how many scheduled runs completed in the last 24 hours, so a gap on our side is visible as a gap, not as a venue problem.
- One sample is noisy. That is why the board also shows a 24-hour average, and why the alert rules we offer require a threshold to be exceeded for five consecutive minutes before firing.
Reproducing it
The procedure is deliberately ordinary: a TLS connection, HTTP/1.1 with keep-alive, four GET requests, a median. Any HTTP client that lets you reuse a connection and time individual requests will give you the same shape of result. If you publish your own numbers from a different location, we would be glad to link to them.
Verfasst vom Engineering-Team von Avtim. Zahlen aus Börsendokumentationen waren zum Zeitpunkt der Erstellung aktuell; Handelsplätze ändern Limits ohne Vorankündigung, prüfen Sie sie daher, bevor Sie darauf aufbauen. Nichts hier stellt eine Anlageberatung dar.