You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a "constant rate" mode for the bench subcommand.
Use case
The current benchmark "as fast as it gets" mode is great, but it doesn't cover all cases one might want to inspect.
One such case is testing fail-over behavior of a nats setup. This could be better tested if we had - e.g. - a "constant rate" mode, that just constantly writes messages (for --pub) and counts them on the other side (for --pub).
This way one can fire messages at different rates and inspect either drop-rate or queue-fill-rate (depending on whether one is using nats streaming or not).
In our specific case we have leaves running on bare-metal and publishing (without streams) to a cluster on k8s. Cluster rollouts currently cause leaves to disconnect/reconnect and drop a few messages in between.
Contribution
I'd love to give it a try!
The text was updated successfully, but these errors were encountered:
Proposed change
Add a "constant rate" mode for the
bench
subcommand.Use case
The current benchmark "as fast as it gets" mode is great, but it doesn't cover all cases one might want to inspect.
One such case is testing fail-over behavior of a nats setup. This could be better tested if we had - e.g. - a "constant rate" mode, that just constantly writes messages (for
--pub
) and counts them on the other side (for--pub
).This way one can fire messages at different rates and inspect either drop-rate or queue-fill-rate (depending on whether one is using nats streaming or not).
In our specific case we have leaves running on bare-metal and publishing (without streams) to a cluster on k8s. Cluster rollouts currently cause leaves to disconnect/reconnect and drop a few messages in between.
Contribution
I'd love to give it a try!
The text was updated successfully, but these errors were encountered: