Manager Performance Improvement PR

Asterisk Asterisk APIs
21

just thinking.

is there a way to log what hit causes the high water mark ?

question the improvement is mostly useful when using the general disabledevents.

if it is not being used will there still be a improvement ?

did not test ..

22

It could log what stasis message, but it’s not the stasis message itself that has caused it and that’s not really useful. It’s a symptom. The rest of the system is the impact.

If disabled events isn’t being used this still provides an improvement, particularly when category based filtering is in use.

23

Does this patch have any affect on systems where the AMI is enabled but not actively used?

24

Unlikely.

25

@benphone Regarding disabled events I wrote the module in test_performance: Add performance experimentation test module. by jcolp · Pull Request #1991 · asterisk/asterisk · GitHub with its CLI commands to better understand the performance characteristics of containers under different usage - including for disabled events. At such a low object count a vector with bsearch ended up being most efficient for disabled events. Once it is merged an AST_VECTOR_BSEARCH will be available which can be used to change disabled events into a sorted ast_vector_string instead.

26

really appreciated this

waiting

i would on top of that already change the disabledevents input type

1 a whitelist enabled events

2 maybe also multiple lines like in the eventfilters

but first i would test and do 1 by 1

27

look pbx05 is hitting short high loads more then the core

trying to figure out the core issue .

do not know the cause but this is my analyses of the manager

if I look the past history and by monitoring in real time the manager task processor is biggest backlog

MaxDepth ,InQueue it is the biggest winner always winning also Processed is double then anything else

MaxDepth InQueue Processed Processor

305419           0       7763711858  stasis/m:manager:core-00000013
 24949           0       3041412484  stasis/m:cel:aggregator-00000012
  4912           0         27217393  stasis/m:devicestate:all-00001e1f
  2758           0       3122438571  stasis/m:cdr:aggregator-00000011
  1542           0           731008  pjsip/options/manage
   700           0             1108  pjsip/mwi-00001179
   403           0             3831  pjsip/mwi-00001174
   403           0          5981352  pjsip/mwi-00001172
   403           0              910  pjsip/mwi-00001175
   402           0              595  pjsip/mwi-00001177
   402           0              636  pjsip/mwi-00001176
   402           0            65278  pjsip/mwi-00001173
   402           0              780  pjsip/mwi-00001178
    64           1        187976854  taskpool/s:pjsip-0000001d
    63           0         12305218  taskpool/s:pjsip-0000001e
    63           0          1383676  taskpool/s:pjsip-00000020
    63           0          2512083  taskpool/s:pjsip-0000001f
    48           0         27274641  stasis/m:devicestate:all-0000000e
    46           0         27263969  stasis/m:devicestate:all-0000000d

edit

i found a stray configuration asterisk was monitoring to much queues fix it should monitor only queues assigned to node and i updated to asterisk to 20.20.1 will continue to monitor