[asterisk-dev] Methodologies for validating dialplan

[Nikša Baldun]

Again, sorry for veering off topic. I'll just say that I have tried 
modifiying Asterisk source. Disabling AMI events helps only a little, 
and disabling Newexten alltogether proved too difficult, at least for 
someone with limited insight into inner workings of Asterisk. If your 
dialplan is indeed 10k lines long, I am reasonably certain you are 
getting frequent task processor warnings in Asterisk log.

On 05. 01. 2022. 00:00, asterisk at phreaknet.org wrote:
> 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/20220105/31a1b57b/attachment.html>