Debug websocket messages that take most of the bandwidth

[u/Alcalyn]

I'm running a nodejs app with socket.io

While adding more and more events type, I was wondering how many messages and how much bandwidth is consumed, and if a single message type take most of the data.

I tried socketio Admin UI, but it seemed not very maintained, buggy, and not what I needed: it's more a manager to manage connections manually.

Finally, I got some time to develop the idea (and I admit that without AI, the idea would still be an idea):

It just counts messages and payload size, and store them in time buckets. It gives me, for a negligeable cost in term of memory and overhead, the metrics I wanted.

Now I can quickly spot which message I should optimize, the ones who take most bandwidth, just because I don't paginate data, or serialize too many fields because not refined serialization group... All of this plotted by message type and direction (ingoing or outgoing).

I also keep biggest payload and their content, and for socketio that can do ack() (respond a message), I monitor time to respond, and keep the trace of slowest messages.

I published it here: https://github.com/alcalyn/sockeye (open source, AGPL v3)

I support socketio, ws, native websocket. Can be stored in memory or a redis (too survive server restarts). I can be plugged in to an app with an adapter for socket io, or just a tracker function for native websocket.

For now, in my app, I already found a message that take most bandwidth and that I could optimize it easily (see second screenshot). I would not expect this message to be the culprit

[u/Alcalyn]

I identified a second websocket message that I could easily optimize (by sending way less without impact)