<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.<br>
</p>
<div class="moz-cite-prefix">On 05. 01. 2022. 14:27,
<a class="moz-txt-link-abbreviated" href="mailto:asterisk@phreaknet.org">asterisk@phreaknet.org</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:80a6c708-3861-50a2-20b3-ed9c97bfb729@phreaknet.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 1/5/2022 5:35 AM, Nikša Baldun
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fdd6867e-5c77-ed86-9222-7ac6f9f41f49@voxdiversa.hr">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>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.</p>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:fdd6867e-5c77-ed86-9222-7ac6f9f41f49@voxdiversa.hr">
<p>If your dialplan is indeed 10k lines long, </p>
</blockquote>
<p>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.</p>
<blockquote type="cite"
cite="mid:fdd6867e-5c77-ed86-9222-7ac6f9f41f49@voxdiversa.hr">
<p>I am reasonably certain you are getting frequent task
processor warnings in Asterisk log.</p>
</blockquote>
<p>I don't believe so... I have seen that a few times, but I
rarely do.<br>
</p>
<blockquote type="cite"
cite="mid:fdd6867e-5c77-ed86-9222-7ac6f9f41f49@voxdiversa.hr">
<div class="moz-cite-prefix">On 05. 01. 2022. 00:00, <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:asterisk@phreaknet.org" moz-do-not-send="true">asterisk@phreaknet.org</a>
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7e161ce4-780a-678a-91f1-7e5b45d97bed@phreaknet.org">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">On 1/4/2022 5:49 PM, Joshua C.
Colp wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAM0A2Z3BnGpq2w6J0iB==RzRfwtt9NDuvdQRqMui7J+gECGzBw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Tue, Jan 4, 2022 at 6:22 PM <<a
href="mailto:asterisk@phreaknet.org"
moz-do-not-send="true" class="moz-txt-link-freetext">asterisk@phreaknet.org</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">That's a really
fair point - maybe another potential source of
improvement?<br>
<br>
I do use AMI for some things, but I have no use for
the "Newexten" and <br>
"Varset" AMI events (if I run my "amidump.php" script,
I'll see hundreds <br>
of these constantly even for a single call).<br>
<br>
In addition, it makes using core set debug >= 3 a
real pain, because <br>
then every complete AMI event is dumped, the result of
which is that 90% <br>
of the debug suddenly becomes an AMI dump of new exten
and new vars.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<p>Thanks, I'll play around with disabling both of them and
see how much that helps.</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:CAM0A2Z3BnGpq2w6J0iB==RzRfwtt9NDuvdQRqMui7J+gECGzBw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>AMI less so, and AMI itself has functionality for
filtering events you don't want.</div>
</div>
</div>
</blockquote>
<p>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.</p>
<p>Disabling these two AMI events in particular, entirely,
would be nice. It seems like disabling the stasis events
might take care of that:</p>
<p>; Use of this functionality may break more complex
functionality in Asterisk<br>
; such as CEL, CDR, transfers, etc. and will likely cause
related messages in ARI<br>
; and AMI to go missing.</p>
<p>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...<br>
</p>
<blockquote type="cite"
cite="mid:CAM0A2Z3BnGpq2w6J0iB==RzRfwtt9NDuvdQRqMui7J+gECGzBw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> Adding an option
to disable generating those events could probably help
<br>
with that, and regardless of the performance benefit,
would make dealing <br>
with debug and AMI a lot easier. I wonder if disabling
snapshots would <br>
also help.<br>
</blockquote>
<div><br>
</div>
<div>Fair warning - things internally depend on
snapshots. Disabling them outright will likely break
things.</div>
</div>
</div>
</blockquote>
Got it, I wasn't as sure about this. I'll probably leave
snapshots alone for now.<br>
<blockquote type="cite"
cite="mid:CAM0A2Z3BnGpq2w6J0iB==RzRfwtt9NDuvdQRqMui7J+gECGzBw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> Can you think of
other things about dialplan which hurt performance <br>
would could be similarly addressed?</blockquote>
</div>
</div>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</blockquote>
</body>
</html>