The WS introduces the HUGE latency for bookTicker streams

Websocket
, ,
1

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

2

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!

3

“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”? :wink:

I want to subscribe to all perpetual futures bookTicker streams.
How can do this? Clarify, please.

4

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!

5

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.

  1. open a socket wss://fstream.binance.com/stream
  2. subscribe to !bookTicker
  3. 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?

6

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!

1 Like
7

  1. How many connections does the server allow from one IP address?
    May I open 20 connections at a time?

  2. Assume I want to subscribe to 100 streams like omniusdt_perpetual@continuousKline_15m
    A size of such a request will be more than 4000 bytes
    What max size of the request does the server support?

Thank you!

8

Hi @Alex324f546t,

Thanks for your follow-up questions! Here are clear answers to your queries:

  1. Maximum WebSocket Connections per IP:
    Binance doesn’t publicly specify a strict connection limit per IP, but opening ~20 simultaneous connections from one IP is generally acceptable. For production systems, it’s best practice to stay conservative and monitor your connection stability closely.
  2. Maximum Size of WebSocket Requests:
    Your intended request (~4,000 bytes) to subscribe to 100 streams is safely within this limit.

For optimal stability, ensure that each connection subscribes to fewer streams (around 100 or fewer per connection is usually a good practice).

Also, in case you intend to use a Binance official connector for your application, you can try the new modularised JS and Java Connectors that expose a pool configuration for websockets, creating multiple connections behind the scenes and managing websocket api requests and/or streams.

Let me know if you need further clarification!