Improvement: message broadcast use case
Opened this issue · 2 comments
Hi @wulczer,
Great plugin, thanks for sharing it!
I filled this issue to present you a use case that would be great to implement.
Say the server has to broadcast a message through WebSocket to all (or a subset) of connected clients. I wondered if it were possible to add kind of probe to measure message delivery time interval, e.g. time between the first received message and the last given a message token (i.e. server broadcasted message delivery time) or time between a broadcast request and the first received message corresponding to this broadcast (i.e. server broadcast request compute time).
Your example shows useful unicast requests, but nothing about broadcast situation where messages are sent to a set of clients (think about tchat room or online games where clients interact with others). Moreover, this would allow us to bench server's underneath WebSocket implementation by varying parameters such as message size, number of delivered clients, etc... and get always more relevant metrics ;)
What do you think about it?
Regards,
Nicolas
Seems like a useful idea, I'm not sure how much of this is possible to compute directly in Tsung, but perhaps there could at least be some helpers to then be able to post-process request logs and extract these numbers.
I saw nothing like timer utility or start/stop trigger to precisely measure time in the Tsung's user manual. Anyway, this is more a feature request about Tsung :)
Maybe we can take advantage of your ack feature (or even the Tsung's transaction mechanism). Say a client sends a broadcast request: it just has to wait for a ack from the server that confirms the broadcast accomplishment. This involves implementing the acknowledgment mechanism server-side and it's not as precise as I wanted (request consideration time, network latency) but it's a good starting point!