Previously on this blog I talked about a new feature to internally filter messages in our internal message bus, as well as a new caching implementation for it. When these were being developed logging had to be manually added to understand the impact. As of the next version of Asterisk a new feature will be available for developers to get some of this information in a more defined mechanism.
Stasis statistics gathering is enabled when Asterisk is built in developer mode and collects statistics on stasis usage and execution. This can be useful if you are wanting to understand the performance of parts of stasis. It provides the following CLI commands:
stasis statistics show messages stasis statistics show subscriptions stasis statistics show topics stasis statistics show subscription <subscription> stasis statistics show topic <topic>
In the case of both “stasis statistics show subscription” and “stasis statistics show topic” tab completion is available for the names.
For “stasis statistics show messages” the usage of specific message types will be output:
Message Type Published Unused stasis_cache_update_type 50 50 stasis_subscription_change_type 77 0 ast_test_suite_message_type 7 0 ast_endpoint_snapshot_type 50 0 ast_endpoint_state_type 2 0 ast_endpoint_contact_state_type 4 0 ast_device_state_message_type 78 0 ast_channel_varset_type 5 1 ast_format_register_type 34 34 ast_manager_get_generic_type 1 0 Total 308 85
We can see here that for a few message types we created messages for them, but there was no subscriber interested in receiving them. This could be a future improvement – not even creating the messages at all in this case.
For “stasis statistics show subscriptions” we get general information about messages that were either dropped by a subscriber or actually accepted by it, as well as processing time.
Subscription Dropped Passed Lowest Invoke Highest Invoke ed691c68-634f-4b19-b265-cd2809840746 2 1 0 0 875f0c6a-b32b-46d6-8b36-73aa0af0fb4e 2 1 0 0
For “stasis statistics show topics” we receive similar information except at a more high-level perspective. This allows you to see whether ANY subscriber on a topic wanted a message or not and the processing time. You may note that there are two topics with the same name here. Currently topic names are not guaranteed to be unique across the system. This will be improved in the future to not just be unique but to also provide more information in the topic name about what the topic is for.
Topic Dropped Dispatched Lowest Dispatch Highest Dispatch PJSIP/mytrunk 0 5 0 0 PJSIP/mytrunk 0 2 0 0
For “stasis statistics show subscription” we get more detailed information about subscriptions. Normally it would be difficult to know what a subscription is actually for or where it originated from but thanks to this CLI command this information is now available.
Subscription: 13e403ee-fe05-4dad-8874-6760c5b67d0f Topic: PJSIP/mytrunk Source filename: endpoints.c Source line number: 267 Source function: endpoint_internal_create Number of messages dropped due to filtering: 3 Number of messages passed to subscriber callback: 1 Using mailbox to queue messages: Yes Using stasis threadpool for handling messages: Yes Lowest amount of time (in milliseconds) spent invoking message: 0 Highest amount of time (in milliseconds) spent invoking message: 0
Finally we have “stasis statistics show topic” which provides a bit more information.
Topic: ast_system Number of messages published that went to no subscriber: 34 Number of messages that went to at least one subscriber: 2 Lowest amount of time (in milliseconds) spent dispatching message: 0 Highest amount of time (in milliseconds) spent dispatching messages: 0 Number of subscribers: 3
Using these CLI commands provides better insight into how exactly stasis is being used and what users of stasis may take a long time to process their messages. This ensures that for stasis improvements we focus on the aspects that actually make an impact to users, and not just areas we think would improve things.
