Get topic frequency without actually subscribing [closed]

asked 2023-04-06 10:52:37 -0500

labude gravatar image


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?

edit retag flag offensive reopen merge delete

Closed for the following reason duplicate question by gvdhoorn
close date 2023-04-17 10:45:54.795994


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".

gvdhoorn gravatar image gvdhoorn  ( 2023-04-07 01:55:07 -0500 )edit

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?

labude gravatar image labude  ( 2023-04-14 16:44:34 -0500 )edit

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.

I would have to enable statistics for a subscribed node which makes the approach less convenient.

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 ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2023-04-15 01:27:42 -0500 )edit

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.

labude gravatar image labude  ( 2023-04-17 07:32:11 -0500 )edit

I suggest we close your question as a duplicate, as it is in essence a duplicate of #q314134.

gvdhoorn gravatar image gvdhoorn  ( 2023-04-17 10:45:39 -0500 )edit