[asterisk-dev] Methodologies for validating dialplan

[asterisk at phreaknet.org]

On 1/5/2022 5:35 AM, Nikša Baldun wrote:
>
> 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.
>
I'll take a closer look at this at some point. Based on what Josh and 
you have confirmed, it will be more difficult to decouple the Newexten 
event, but just because this is the way it is now doesn't mean it has to 
stay that way. Surely there is a way to turn it off (besides brute force 
commenting code out), even if it requires some mucking around, and doing 
so would have tangible benefits it sounds like.
>
> If your dialplan is indeed 10k lines long,
>
I hadn't checked in a while... my dialplan is currently 24,000 lines at 
the moment, though I've been able to shrink great parts of it by writing 
specific custom C modules to replace frequent or inefficient subroutines 
that did rather generic tasks, so it used to be even larger (not mainly 
in terms of total lines registered in the dialplan, but more in terms of 
# of dialplan priorities executed per call - some of these reduced 
hundreds of dialplan executions into a single function call). This has 
also helped greatly with making the dialplan more concise and efficient. 
Using Set(ARRAY) or MSet to do multiple sets at once also helps reduce # 
of executed priorities. I haven't experienced the noticeable delays with 
dialplan that you had mentioned, before or after, but I'm probably not 
doing what you are.

> I am reasonably certain you are getting frequent task processor 
> warnings in Asterisk log.
>
I don't believe so... I have seen that a few times, but I rarely do.

> 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/7aa0c4e2/attachment-0001.html>