|
SObjectizer
5.5
|
Amount of monitoring information from dispatchers has been expanded in v.5.5.18. It is now possible to receive information about time spent inside event-handlers and time spent during waiting for next event.
Collecting of such information must be turned on explicitely. This information is not collected by default to avoid negative impact on dispatchers' performance. Work thread activity tracking can be turned on for an individual dispatcher:
It can be also done for the whole SObjectizer Environment:
In that case collecting of information of work thread activity will be turned on for all dispatchers inside SObjectizer Environment. If it is not appropriate for some dispatcher then thread activity tracking can be turned off in parameters of that dispatcher:
Distribution of information about work thread activity is done the usual way – by messages which are sent to message box of stats_collector. These messages have type work_thread_activity which is defined in so_5::stats::messages namespace.
There ara well known fields m_prefix and m_suffix inside work_thread_activity. Also there are additional fields:
m_thread_id with ID of working thread (activity stats information is related to thread with this ID);m_working_stats with info about time spent in event-handlers;m_waiting_stats with info about time spent on waiting for new events.Fields m_working_stats and m_waiting_stats have type so_5::stats::activity_stats_t:
Where duration_t is std::chrono::high_resolution_clock::duration or std::chrono::steady_lock::duration.
Message work_thread_activity allows to know how many events have been handled by a work thread (from the very beginning of its work), how much time have been spent inside event-handlers (from the very beginning of its work), average time of event-handler's work. Similary for waiting of new events (e.g. count of waitings, total time spent in waiting, average waiting time).
This is a small example of how that information can looks like:
This is a dump of monitoring info for adv_thread_pool-dispatcher with four work threads. A single coop with five agents inside works on that dispatcher. It is possible to see info for every work thread (there is thread ID in square brackets). For this particular case it is possible to see that work threads spend more time during waiting for new events that for event-handling.
Some words about performance impact. It highly depends of dispatcher's type and load profile. For one_thread-dispatcher and heavy message-stream this impact is negligible. But for active_obj-dispatcher with occasional messages performance can degraded for 3-4 times. Becase of that it impossible to provide some numbers of cummulative performance loss: there is too big variety in results.
In any cases this mechanism is regarded as auxilary. It indended to debugging and profiling. Because of that it is necessary to check performance impact of work thread activity tracking on your application. And only then the decision about turning that tracking on in production evironment must be taken.
1.8.14