Araştırma
Pay once, pay per order: where the time actually goes between you and a venue
A trading connector spends time in two very different ways. Some costs are paid once per connection; some are paid on every order. Mixing them is the most common reason latency work goes nowhere.
Araştırma makaleleri İngilizce yayımlanır.
Ask an engineer how long it takes to send an order to an exchange and you will usually get one number. That number is almost always wrong, not because the measurement was bad, but because it adds together things that happen at different times. This note separates them.
Costs paid once
These are paid when a connection is established and then amortised over everything that flows through it.
DNS resolution. One lookup per host name, cached afterwards. Negligible in steady state, but it is on the critical path of a reconnect, and some venues rotate the addresses behind a name, so a cached answer can go stale.
TCP handshake. One round trip to the venue’s TLS endpoint. If the venue sits behind a content delivery network, that endpoint is an edge node and the handshake is short; the real distance is hidden behind it.
TLS handshake. One round trip with TLS 1.3, two with TLS 1.2, plus a little CPU for the key exchange. Session resumption can cut this on venues that support it.
Session login. On venues with WebSocket order entry, the client authenticates once per connection: a signed login message, or an API key bound to the session. After that, individual orders are not signed again.
Subscriptions. For market data, the client subscribes once; the venue then pushes. For private data, the same: orders, fills, positions and balances arrive on a stream the client opened once.
Everything in this list is a reconnect cost. A connector that reconnects rarely barely notices it. A connector that reconnects often, because the venue drops idle connections or because the client’s own error handling tears down the socket on every hiccup, pays it constantly and shows up as “slow” in every measurement without any single request being slow.
Costs paid per order
These are paid on the hot path, for every order, and they are what a strategy actually waits for.
Serialisation. Building the request body. Trivial for JSON on a modern CPU, until a connector builds it through three layers of generic abstractions.
Signing. Most REST order endpoints require an HMAC over the request parameters. A SHA-256 HMAC takes microseconds; the surrounding string formatting and encoding often takes longer than the hash. On venues with WebSocket order entry and session login, this cost disappears from the per-order path, which is the main reason those endpoints are faster.
The network round trip. From the client’s socket to the venue’s gateway and back. This is the number people mean when they say “latency”, and it is the one the Latency Monitor’s request figure approximates for a public endpoint.
Gateway processing. Authentication checks, rate-limit accounting, request validation, and the hop from the gateway to the matching engine. Invisible from outside, but it is why a venue whose gateway is near you can still acknowledge orders slowly, and why two venues with the same network round trip can differ by a lot on order acknowledgement.
Response parsing. Reading the acknowledgement. Again trivial, unless the parser is generic and the response is large.
Why keeping them apart matters
Three practical consequences follow.
First, measure them separately or the measurement will mislead you. A benchmark that opens a fresh connection for every order measures the reconnect cost over and over and will tell you that a venue is slow when its gateway is fine. The probe behind our monitor discards the first request on a new connection for exactly this reason; a trading connector should keep connections alive for the same reason.
Second, optimise the right bucket. If your orders are slow because the connector reconnects on every error, no amount of work on signing will help. If reconnects are rare and the order path is slow, the reconnect cost is irrelevant and the work belongs in serialisation, signing and the choice of endpoint.
Third, prefer endpoints that move cost from the per-order bucket to the once bucket. WebSocket order entry with session login does this by design. FIX does it more aggressively. REST with per-request signatures does the opposite. When a venue offers more than one, the difference between them is usually larger than any optimisation you can make inside the client.
A note on clocks
Signed REST requests carry a timestamp, and venues reject requests whose timestamp is too far from their own clock. This looks like a per-order cost when it fails, but it is a once-per-connection problem in disguise: the offset between your clock and the venue’s should be measured when the connection is established and corrected continuously, not discovered through rejected orders. We wrote about that separately in Clock skew and signed requests.
Avtim mühendislik ekibi tarafından yazılmıştır. Borsa belgelerinden aktarılan rakamlar yazıldığı tarihte günceldi; işlem yerleri sınırlarını önceden haber vermeden değiştirir, bu nedenle bu rakamlara dayanarak bir şey geliştirmeden önce doğrulayın. Buradaki hiçbir içerik yatırım tavsiyesi değildir.