The WS introduces the HUGE latency for *@bookTicker streams
Hi
There is an example of the trivial application to measure the latency
This application just opens the WS stream and subscribes to all trading perp future bookTickers
The server stars sending the data and then… The latency increases and server breaks the connection.
Is this an intended behavior?
The source files of the application are here
Hi @Alex324f546t,
Thanks for raising this! The latency and eventual disconnection you’re seeing are likely related to how many bookTicker
streams you’re subscribing to in one WebSocket connection.
Binance WebSocket infrastructure does impose soft limits:
The wss://fstream.binance.com/stream
endpoint allows up to 1024 streams per connection, but real-world performance may degrade much earlier.
Subscribing to all perpetual futures bookTicker
streams can result in high data throughput, which may cause increased latency or connection throttling.
Suggestions:
- Split subscriptions across multiple connections, each handling a smaller batch of streams.
- Consider filtering only for the most relevant symbols or using the
!bookTicker
stream, which aggregates updates.
Let us know if that worked for you!
“Split subscriptions across multiple connections, each handling a smaller batch of streams.”
Result is the same. The server disconnects the socket form time to time if all perpetual futures bookTicker streams are subscribed.
" Consider filtering only for the most relevant symbols or using the !bookTicker
stream, which aggregates updates."
The !bookTicker
stream disconnects from time to time too.
It seems the issue is not related to the network. The VPS is located in Tokyo.
“…but real-world performance may degrade much earlier.”
Hm… Is it because the problems with your servers? I see the server sometimes returns the error “The server is too busy. Try later…” How is it possible to have the server “busy” if you want to be a “top level exchange”?
I want to subscribe to all perpetual futures bookTicker
streams.
How can do this? Clarify, please.
Hi @Alex324f546t,
Thanks for the clarification.
The latency and occasional disconnections you’re experiencing are due to the very high data throughput generated by subscribing to all perpetual futures bookTicker
streams simultaneously. Binance WebSocket infrastructure can handle up to 1024 streams per connection; however, for best real-world performance, especially with intensive streams like bookTicker
, it’s recommended to:
- Split subscriptions across multiple WebSocket connections, each managing fewer symbols.
- Prioritize relevant symbols rather than subscribing to all available streams at once.
This is consistent with industry best practices for handling high-frequency streaming data reliably and efficiently.
BTW, which WS URL are you using?
Let us know if you have additional questions!
hi dimitrisn
Thank you for you answer.
The general idea is clear. This does not help to reduce the latency.
I subscribed to the stream !bookTicker
(All Book Tickers Stream | Binance Open Platform)
The server sends the data with the initial latency 20…60ms
It is easy to check.
- open a socket wss://fstream.binance.com/stream
- subscribe to
!bookTicker
- check the timestamp
2025-05-03 07:49:20.334 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p550)A raw message latency is 45ms for {“stream”:“!bookTicker”,“data”:{“e”:“bookTicker”,“u”:7416160978290,“s”:“LINKUSDC”,“b”:“14.404”,“B”:“89.41”,“a”:“14.407”,“A”
:“30.47”,“T”:1746258560289,“E”:1746258560289}}
1746258560289 = Saturday, May 3, 2025 7:49:20.289 AM
The local time is 2025-05-03 07:49:20.334
334 - 289 = 45 ms
I am connecting from 45-130-166-173.cloud-xip.com
The round trip for the SUBSCRIBE command is about 100ms
2025-05-03 08:00:10.361 | INFO | | B.FutTopQuoteListCombinedRawWs - Subscribe to {“method”:“SUBSCRIBE”,“id”:3,“params”:[“!bookTicker”]}
2025-05-03 08:00:10.462 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p160) onMessage: message {“result”:null,“id”:3}
The VPS has a 100Gb/s WAN port.
The CPU load is 10…25%
“BTW, which WS URL are you using”
I am using this URL
wss://fstream.binance.com/stream
The host fstream.binance.com does not answer on ping requests.
trader@trader-1:~/signalTrader/logs$ ping api.binance.com
PING d3h36i1mno13q3.cloudfront.net (3.169.4.182) 56(84) bytes of data.
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=1 ttl=249 time=3.19 ms
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=2 ttl=249 time=3.27 ms
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=3 ttl=249 time=3.12 ms
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=4 ttl=249 time=3.14 ms
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=5 ttl=249 time=3.13 ms
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=6 ttl=249 time=3.18 ms
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=7 ttl=249 time=3.18 ms
64 bytes from server-3-169-4-182.nrt57.r.cloudfront.net (3.169.4.182): icmp_seq=8 ttl=249 time=3.21 ms
The VPS time is the same as a server`s time
2025-05-03 09:16:57.809 | INFO | main | D.ta4j.BackTesterStartPoint - Server time is {“serverTime”:1746263817809}
1746263817809 == GMT: Saturday, May 3, 2025 9:16:57.809 AM
There are several message that received at the same time but with different INITIAL latency.
You can see the outgoing and receiving time. It looks like the server is unable to send the messages in time for some reasons.
2025-05-03 09:39:29.541 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p550)A raw message latency is 58ms for {“stream”:“!bookTicker”,“data”:{“e”:“bookTicker”,“u”:7416593990020,“s”:“BTCUSDT”,“b”:“96238.50”,“B”:“14.908”,“a”:“96238.60”
,“A”:“1.068”,“T”:1746265169483,“E”:1746265169483}}
2025-05-03 09:39:29.541 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p550)A raw message latency is 56ms for {“stream”:“!bookTicker”,“data”:{“e”:“bookTicker”,“u”:7416593990086,“s”:“DOGEUSDC”,“b”:“0.179360”,“B”:“42010”,“a”:“0.179370”
,“A”:“5262”,“T”:1746265169485,“E”:1746265169485}}
2025-05-03 09:39:29.542 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p550)A raw message latency is 42ms for {“stream”:“!bookTicker”,“data”:{“e”:“bookTicker”,“u”:7416593990771,“s”:“PUMPUSDT”,“b”:“0.0827100”,“B”:“2565”,“a”:“0.0827200
“,“A”:“364”,“T”:1746265169500,“E”:1746265169500}}
2025-05-03 09:39:29.542 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p550)A raw message latency is 37ms for {“stream”:”!bookTicker”,“data”:{“e”:“bookTicker”,“u”:7416593991172,“s”:“RAREUSDT”,“b”:“0.0634600”,“B”:“3119”,“a”:“0.0634700
“,“A”:“16024”,“T”:1746265169505,“E”:1746265169505}}
2025-05-03 09:39:29.542 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p550)A raw message latency is 36ms for {“stream”:”!bookTicker”,“data”:{“e”:“bookTicker”,“u”:7416593991219,“s”:“CTSIUSDT”,“b”:“0.0659”,“B”:“91653”,“a”:“0.0660”,“A”
:“161842”,“T”:1746265169506,“E”:1746265169507}}
2025-05-03 09:39:29.542 | INFO | OkHttp https://fstream.binance.com/… | B.FutTopQuoteListCombinedRawWs - (p550)A raw message latency is 28ms for {“stream”:“!bookTicker”,“data”:{“e”:“bookTicker”,“u”:7416593991540,“s”:“ZILUSDT”,“b”:“0.01269”,“B”:“95974”,“a”:“0.01270”,"A
":“853430”,“T”:1746265169514,“E”:1746265169514}}
UPD:
2025-05-03 12:04…12:12 the server was unable to send the data for !bookTicker
The latency was 100…900 ms
If the market is quiet the sever sends the data in time.
It seems the server sends the data with a latency.
The question is:
How to reduce the INITIAL latency of the message in the stream !bookTicker
, please?
Hi @Alex324f546t,
Thanks for providing detailed data!
The latency you’re measuring (~20–60ms baseline, occasionally spiking during high market activity) primarily reflects server-side message processing and WebSocket distribution timing rather than your network latency or VPS performance.
The fluctuations and occasional latency spikes (100–900ms during market peaks) result from Binance WebSocket infrastructure handling bursts of data across all perpetual futures symbols simultaneously. Even the aggregated stream (!bookTicker
) can experience delays under high market volatility due to the sheer volume of real-time data updates.
Practical ways to minimize latency:
- Multiple Dedicated Connections:
Split your subscriptions into smaller subsets of symbols across multiple WebSocket connections. Having fewer symbols per connection reduces the data load and helps minimize internal delays at peak times. - Selective Subscription:
Prioritize and subscribe only to high-priority symbols that are critical for your trading strategy, further reducing potential delays.
Regarding Server Behavior:
- Occasional latency during market volatility is common across major exchanges due to real-time data processing limits.
- Binance continuously optimizes performance but inherent delays at peak moments are normal and unavoidable due to market dynamics.
In short, the best immediate way to reduce latency is spreading subscriptions across multiple dedicated WebSocket connections with fewer symbols each.
Hope this clarifies and helps you optimize your setup further!