[asterisk-dev] Methodologies for validating dialplan

[Nikša Baldun]

Well, sure, if you offload parts of the dialplan to custom C modules, 
you'll significantly reduce the number of dialplan priorities executed 
per call, and you won't have as much of a problem. But that is 
essentially the same as using AGI, only several orders of magnitude more 
difficult. A combination of dialplan and AGI is probably a way to go for 
most people (so your work on catching dialplan errors will certainly 
help), but personally I've found it much easier to just do everything in 
AGI. In some way, I am grateful for the performance problem I've had, 
because it made me rewrite call flow logic using a tool I am much 
happier with.

On 05. 01. 2022. 14:27, asterisk at phreaknet.org wrote:
> 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/20220107/145680bd/attachment.html>