Get topic frequency without actually subscribing
Hello,
I want to know the frequencies of some topics for diagnostic purposes (throw a warning if too high or low). My current approach is to subscribe to each topic and count the messages coming in, then take the average of the inter-arrival times. This generally works, but it causes a lot of traffic if I subscribe to many topics or camera images etc. as they need to be sent through the network.
I am not interested in the actual message data, just need to know that/when a message was published. Is there a way to obtain such meta data without really subscribing to the topic?
Asked by labude on 2023-04-06 10:52:37 UTC
Comments
See whether #q314134 answers this.
It will require actual subscribers to exist for a specific topic, but I guess you can infer "no statistics -> no subscribers".
Asked by gvdhoorn on 2023-04-07 01:55:07 UTC
Thanks for this hint, very helpful.
The only drawback in my eyes: You can only enable statistics for all topics/connections. To reduce overhead, I remapped the
enable_statistics
argument for the node that publishes the topics I am interested in. However, this only yields statistics for the subscriptions of this node, not the publications. So, in order to get the publish rate of a node, I would have to enable statistics for a subscribed node which makes the approach less convenient.Am I missing something or would you suggest to simply enable statistics for all connections disregarding possible overhead?
Asked by labude on 2023-04-14 16:44:34 UTC
Enabling statistics is indeed typically application-wide.
re: overhead: I wouldn't actually know what the overhead is. The statistics are stored/updated at the client library level, and are all local to the node. The data and calculations are internal to nodes, and unless someone subscribes to the
/statistics
topic, it doesn't "go anywhere", implying overhead up to that point is probably low (for average messaging rates).But I've not measured it, so this is all me guestimating.
well the only other alternative I could come up with would be a generic subscriber, implementing bookkeeping yourself (ie: arrival times) and discarding the actual message content.
But that would probably be even more costly as it would require you to subscribe to every publisher you're interested in, and would force that publisher to actually send you a complete msg, which you then throw away.
Asked by gvdhoorn on 2023-04-15 01:27:42 UTC
That sounds reasonable, thanks again. I've implemented it using TopicStatistics and so far it seems to do what I needed.
You could turn your comment into an answer if you want to.
Asked by labude on 2023-04-17 07:32:11 UTC
I suggest we close your question as a duplicate, as it is in essence a duplicate of #q314134.
Asked by gvdhoorn on 2023-04-17 10:45:39 UTC