Optimizing Latency
For latency-sensitive traders and high-frequency strategies, every millisecond counts. QuBit is dedicated to providing a high-performance trading infrastructure. This document outlines a series of strategies and best practices you can adopt to effectively reduce the latency of your API interactions.
1. Networking & Deployment
Network latency is the most significant factor affecting API performance. Deploying your trading application in close physical proximity to QuBit's servers can dramatically reduce the round-trip time (RTT) for data transmission.
Server Location: QuBit's API server clusters are deployed in the AWS Singapore (ap-southeast-1) region.
Best Practice: To achieve the lowest possible physical network latency, we highly recommend deploying your trading servers on AWS EC2 instances within the same region.
You can use the ping api.qubit.com command to test the network latency from your current location to our servers.
2. Use the WebSocket API for Real-Time Data
For any scenario that requires real-time market data, you should never use polling of REST API endpoints.
WebSocket vs. REST:
WebSocket API: Employs a server-push model. Once you subscribe to a channel, the server actively and instantly pushes data updates to you over a single, persistent connection. This is the most efficient, lowest-latency method for data retrieval.
REST API: Uses a request-response (pull) model. Each data fetch requires a new HTTP request, which includes overheads like network connection setup and TLS handshakes, resulting in much higher latency than WebSocket.
Best Practice:
Use the WebSocket API to subscribe to the
bookschannel to build and maintain a real-time order book locally.Use the WebSocket API to subscribe to the
tickersandtradeschannels for the latest market prices and executions.Use the REST API only when you need to perform actions (like placing or canceling orders) or query non-real-time data (like order history).
3. API Usage Tips
Maintain Persistent HTTP Connections (Keep-Alive):
Enable the Keep-Alive feature in your HTTP client. This allows your application to send multiple REST API requests over a single TCP connection, avoiding the overhead of re-establishing a connection for every request. Most modern HTTP libraries enable this by default.
Use Batch Operations:
When you need to cancel multiple orders, use the
POST /api/v1/trade/cancel-batch-ordersendpoint. Canceling multiple orders in a single request is far more efficient than sending a separate cancel request for each order.
Avoid Unnecessary Requests:
Fetch and cache information that does not change frequently, such as instrument details (
GET /common/instruments), at the start of your application. Do not re-request this data before every trade.Leverage the data pushed via WebSocket. For example, when an order's status changes, you will receive a notification through the
orderschannel, eliminating the need to poll the order status via the REST API.
4. Client-Side Performance
Efficient JSON Parsing:
Choose a high-performance JSON parsing library in your application. For Go, the standard library's
encoding/jsonoffers excellent performance; for other languages, consider high-performance libraries likesimdjson.
Asynchronous Processing:
Execute your network I/O (sending API requests, processing WebSocket messages) asynchronously in separate threads or goroutines from your core strategy calculation logic. This prevents network latency from blocking your strategy computations.
By combining the strategies above, you can minimize unnecessary latency and ensure your trading instructions are received and processed by QuBit's matching engine as quickly as possible.
Last updated