You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the discussion in #2129, I conducted tests comparing HTTP and WebSocket order placement performance on Bybit.
Under identical code and parameter configurations, I collected two key metrics on both Server A and Server B:
During this period, there's been some slight volatility in the market.
Test Results
elapsed_ns_order_init_to_submitted
elapsed_ns_order_init_to_accepted
At a certain point, HTTP order placement experienced a sudden and prolonged latency increase.
After restarting the strategy, the latency returned to normal, though the exact cause is still unclear.
Excluding that time window, the comparison results between the two methods are as follows:
elapsed_ns_order_init_to_submitted
elapsed_ns_order_init_to_accepted
Conclusions
WebSocket offers a huge speed advantage over HTTP, and more stable.
Data from node_exporter shows that when using HTTP-only, TCP_inuse fluctuates more significantly compared to WS-only, likely due to connection recycling mechanisms.
In the current code, event.ts_event uses the timestamp from the WebSocket message under the order topic, specifically the updatedTime field.
Additionally, In my other test, it shows Bybit’s WebSocket messages createdTime and updatedTime differ by about 3–4 ms.
Even when both servers use WS-only, Server A and Server B still show some discrepancies, likely due to factors such as “noisy neighbors,” differences in matching engines behind different accounts, and physical distance from the exchange servers. However, these variations are less pronounced than the discrepancy observed with HTTP.
Question
It is currently impossible to measure the exact duration from “order initialization” to the moment the request is actually sent, because generate_order_submitted is the final step executed just before sending the request.
In my implementation, there is almost no additional logic between self.order_factory and self.submit_order, so elapsed_ns_order_init_to_submitted effectively reflects the internal processing overhead of nautilus_trader from order creation to just before sending the request.
Is there any way to optimize the elapsed time here?
cjdsellers
changed the title
Comparison of Bybit HTTP vs WebSocket Order Placement Speed
Comparison of Bybit HTTP vs WebSocket order placement speed
Dec 31, 2024
cjdsellers
changed the title
Comparison of Bybit HTTP vs WebSocket order placement speed
RFC: Comparison of Bybit HTTP vs WebSocket order placement speed
Jan 9, 2025
Background
Based on the discussion in #2129, I conducted tests comparing HTTP and WebSocket order placement performance on Bybit.
Under identical code and parameter configurations, I collected two key metrics on both
Server A
andServer B
:elapsed_ns_order_init_to_submitted
:OrderInitialized -> OrderSubmitted
elapsed_ns_order_init_to_accepted
:OrderInitialized -> OrderAccepted
Instrument ID
ETHUSDT-LINEAR.BYBIT
Configuration
HTTP-ONLY
use_ws_trade_api=False
use_http_batch_api=True
WS-ONLY
use_ws_trade_api=True
use_http_batch_api=False
Time Range (UTC)
2024-12-26 11:00:00 ~ 2024-12-26 13:00:00
During this period, there's been some slight volatility in the market.
Test Results
elapsed_ns_order_init_to_submitted
elapsed_ns_order_init_to_accepted
At a certain point, HTTP order placement experienced a sudden and prolonged latency increase.
After restarting the strategy, the latency returned to normal, though the exact cause is still unclear.
Excluding that time window, the comparison results between the two methods are as follows:
elapsed_ns_order_init_to_submitted
elapsed_ns_order_init_to_accepted
Conclusions
node_exporter
shows that when using HTTP-only,TCP_inuse
fluctuates more significantly compared to WS-only, likely due to connection recycling mechanisms.event.ts_event
uses the timestamp from the WebSocket message under theorder
topic, specifically theupdatedTime
field.createdTime
andupdatedTime
differ by about3–4
ms.Server A
andServer B
still show some discrepancies, likely due to factors such as “noisy neighbors,” differences in matching engines behind different accounts, and physical distance from the exchange servers. However, these variations are less pronounced than the discrepancy observed with HTTP.Question
generate_order_submitted
is the final step executed just before sending the request.self.order_factory
andself.submit_order
, soelapsed_ns_order_init_to_submitted
effectively reflects the internal processing overhead ofnautilus_trader
from order creation to just before sending the request.Code used for measurement
@cjdsellers @filipmacek
The text was updated successfully, but these errors were encountered: