How to measure Websocket backpressure or network buffer from client

user_1260245 0
Viewed 1455

I am using the ws Node.js package to create a simple WebSocket client connection to a server that is sending hundreds of messages per second. Even with a simple onMessage handler that just console.logs incoming messages, the client cannot keep up. My understanding is that this is referred to as backpressure, and incoming messages may start piling up in a network buffer on the client side, or the server may throttle the connection or disconnect all-together.

How can I monitor backpressure, or the network buffer from the client side? I've found several articles speaking about this issue from the perspective of the server, but I have no control over the server and need to know just how slow is my client?

backpressure node.js websocket
3 Answers
user_11859610

Add timing metrics to your onMessage function to track how long it takes to process each message. You can also use RUM instrumentation like from the APM providers -- NewRelic or Appdynamics for paid options or you could use free tier of Google Analytics timing.

If you can, include a unique identifier for correlation between the client and server for each message sent.

Then you can correlate for a given window how long a message took to send from the server and how long it spent being processed by the client.

You can't get directly to the network socket buffer associated with your websocket traffic since you're inside the browser sandbox. I checked the WebSocket APIs and there's no properties that expose receive buffer information.

user_116303600

If you don't have control over the server, you are limited. But you could try some client tricks to simulate throttling.

This heavily assumes you don't mind skipping messages.

One approach would be to enable the socket, start receiving events and set your own max count in a in-memory queue/array. Once you reach a full queue, turn off the socket. Process enough of the queue, then enable the socket again.

This has high cost to disable/enable the socket, as well as the loss of events, but at least your client will not crash.

Once your client is not crashing, you can put some additional counts on timestamp and the queue size to determine the threshold before the client starts crashing.

user_61914840
Related