[asterisk-dev] Methodologies for validating dialplan

[asterisk at phreaknet.org]

On 1/4/2022 5:49 PM, Joshua C. Colp wrote:
> On Tue, Jan 4, 2022 at 6:22 PM <asterisk at phreaknet.org> wrote:
>
>     That's a really fair point - maybe another potential source of
>     improvement?
>
>     I do use AMI for some things, but I have no use for the "Newexten"
>     and
>     "Varset" AMI events (if I run my "amidump.php" script, I'll see
>     hundreds
>     of these constantly even for a single call).
>
>     In addition, it makes using core set debug >= 3 a real pain, because
>     then every complete AMI event is dumped, the result of which is
>     that 90%
>     of the debug suddenly becomes an AMI dump of new exten and new vars.
>
>
> Stasis events can be disabled in stasis.conf, I don't know the 
> ramifications of disabling new exten but varset is fine. Generating 
> the stasis events is what can be expensive.

Thanks, I'll play around with disabling both of them and see how much 
that helps.

I see "ast_channel_varset_type" in stasis.conf - which one would be the 
right one for disabling Newexten? I poked around the code a bit but I'm 
not following the connection as much.

> AMI less so, and AMI itself has functionality for filtering events you 
> don't want.

That's true (and I do filter) but AMI itself is still processing the 
event, so it'll mean a waterfall of AMI dumps with core set debug >= 3, 
and perhaps the overhead is still significant for a large dialplan.

Disabling these two AMI events in particular, entirely, would be nice. 
It seems like disabling the stasis events might take care of that:

; Use of this functionality may break more complex functionality in Asterisk
; such as CEL, CDR, transfers, etc. and will likely cause related 
messages in ARI
; and AMI to go missing.

I don't use ARI at all - or CEL - so as long as CDR remains intact, I 
could probably shut off a few of these...

>     Adding an option to disable generating those events could probably
>     help
>     with that, and regardless of the performance benefit, would make
>     dealing
>     with debug and AMI a lot easier. I wonder if disabling snapshots
>     would
>     also help.
>
>
> Fair warning - things internally depend on snapshots. Disabling them 
> outright will likely break things.
Got it, I wasn't as sure about this. I'll probably leave snapshots alone 
for now.
>
>     Can you think of other things about dialplan which hurt performance
>     would could be similarly addressed?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20220104/bc203543/attachment.html>