Looking for Interceptor on Publish to handle Backpressure

[ironydips]

Trying my hands on uwebsockets.js first time. Super fine experience but stuck badly now.

We have 1000 clients connected to nodejs uws. And we have to send same data (~350KB) to all clients as they subscribed by default on open. For this we are calling publish but 30% of the msgs are getting lost due to Backpressure.

How do we handle this as we do not see any method to interfere after publish is called, data directly goes to Client or fails.

Some Code Snippet is highly appreciated.

Also, things are pretty smooth when we run on local machine, but on ec2 server Backpressure issue becomes 100 times more

[e3dio]

Adjust your settings: maxBackpressure, closeOnBackpressureLimit

And minimize your data size. How often are you publishing 350kb to 1000 clients? Are you sure that is the smallest possible size? What kind of data/format is taking up 350kb on every publish?

[ironydips]

Though I am reading a lot about maxBackpressure, can not get full hold of it.

• Data Transfer Frequency is every 1 min.
• Clients will gradually increase to 10,000 once we are fully confident of msgs not being dropped as our data is related to Stock Market and timely updates are super crucial for financial markets
• we are stringifying data using JSON currently, exploring other ways of fast mechanism & to reduce size.

const app = uWS.App()
app.ws('/*', {
     compression: uWS.SHARED_COMPRESSOR,
     maxPayloadLength: 16 * 1024,
     idleTimeout: 30,
     maxBackpressure: 1024 * 100
})

[ironydips]

that clears all the compression doubts. also, this is the production data I shared and since many values are repeated (normal for our use case) I now see why gzip worked just fine.

since data is now reduced to under 40kb now (thanks to you), I shall now monitor my original problem of BackPressure & get back with my findings/further queries.

not sure if this is right forum to ask this or not, I am dedicatedly using aws ec2 server as r6.xlarge for websocket purpose, can you pls suggest if such instances are optimal for sending ~40kb of data every minute to roughly 3000 users. Or what kind of configuration should we look for in server instance?

[e3dio]

Ec2 has at least 5 Gb per second network out, your data is 40kB * 3000 = .12GB = .96Gb per minute so it has more than enough out

[e3dio]

I Gzip'd the PackBytes encoding and it was 3x faster and 22% smaller than Gzip+Json, so if you really want the smallest size you know what to do ;)

.	Bytes
Gzip+PackBytes	9,271
Gzip+Json	12,033
PackBytes	14,839
Avsc	18,843
Json	73,648

[ironydips]

I also just tried the same gzipping packbytes and was about to post here.. way to go. :)

just confused about the D: bits(8) rest all clear :)

[e3dio]

Max value for D was 230504 and min value was 230320 which means there are 184 possible values which requires 8 bits to represent. You say this represents a Date field, you can change this field to represent 'number of days since X date' and use however many bits are needed, convert back to Date after decode

[e3dio]

Looking for Interceptor on Publish to handle Backpressure

Should also mention to answer original question, if you want to handle each websocket connection individually depending on backpressure level, loop through each websocket and check ws.getBufferedAmount() for backpressure, and send custom messages with ws.send() instead of app.publish(). But most important thing is get data size as small as possible, then you have less backpressure