<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
On 2021/01/11 13:47, Joshua C. Colp wrote:<br>
<blockquote type="cite"
cite="mid:CAM0A2Z2hZTA7Xca+OvmfKbOUYy1SoC0JezwA9hG2oZaEhn+7cA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Mon, Jan 11, 2021 at 7:38 AM Jaco Kroon <<a
href="mailto:jaco@uls.co.za" moz-do-not-send="true">jaco@uls.co.za</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">Hi All,<br>
<br>
I am very much new to the way in which statis functions. Is
there<br>
documentation somewhere around the design of this I should
be looking at?<br>
</blockquote>
<div><br>
</div>
<div>It depends on what you mean by design and of what. Stasis
itself is a message bus[1]. Message gets queued, subscribers
receive it. CDRs are a consumer of it, and it has its own
implementation and behavior in conjunction with Stasis.</div>
<div><br>
</div>
<div>[1] <a
href="https://wiki.asterisk.org/wiki/display/AST/The+Stasis+Message+Bus"
moz-do-not-send="true">https://wiki.asterisk.org/wiki/display/AST/The+Stasis+Message+Bus</a></div>
</div>
</div>
</blockquote>
<p>More like the API to statis itself, the above is a very high
level overview, and it's a good place to start, and I'll move to
the header files next (these tend to be fairly well documented
nowadays).<br>
</p>
<blockquote type="cite"
cite="mid:CAM0A2Z2hZTA7Xca+OvmfKbOUYy1SoC0JezwA9hG2oZaEhn+7cA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Our primary issue is that both cdr_read and cdr_write in
func/func_cdr.c<br>
gets very slow (up to four seconds, sporadically). We're
using cdr_odbc<br>
back-end.<br>
<br>
We suspect after looking into the code on func_cdr side that
this is due<br>
to stasis basically sending a message via statis to the cdr
engine, and<br>
then getting delayed due to the SQL process sometimes being
slow on<br>
COMMIT phase of transactions.<br>
</blockquote>
<div><br>
</div>
<div>If not using batching then certainly possible.</div>
</div>
</div>
</blockquote>
<p>Thanks for the confirmation.<br>
</p>
<blockquote type="cite"
cite="mid:CAM0A2Z2hZTA7Xca+OvmfKbOUYy1SoC0JezwA9hG2oZaEhn+7cA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
I'm thinking of a few possible things that can be done here
on the<br>
asterisk (without having checked whether this may be the
case already):<br>
<br>
1. Switch to batched processing (which hopefully posts
multiple<br>
transactions in a single transaction).<br>
2. Decouple finalization of CDRs from the main CDR thread.<br>
3. Semi batch process where if (and only if) CDRs batch up
they're<br>
batch processed into a single transaction (ie, grab all
outstanding,<br>
post them, reply success to all).<br>
<br>
Happy to put in the work, would just like to understand
better as to how<br>
this works so that I don't lay down a fair amount of work
for little to<br>
no gain at all.<br>
<br>
From a hardware side we're also busy looking into upgrades
w.r.t. disks<br>
that may help (one consideration is to just add a small NVMe
just for<br>
the SQL database). Just to be clear we're not just
attacking this from<br>
one front.<br>
</blockquote>
<div><br>
</div>
<div>Looking at the CDR batch documentation it appears to
provide a good amount of configuration - such as maximum
number before batching as well as time, so I think that'd be
best to investigate.</div>
</div>
</div>
</blockquote>
<p>Ok. I'll dig into these a bit thank you. Hoping that I can
somehow get to group multiple CDRs into single transactions ...
which would be the single greatest win.<br>
</p>
<p>Kind Regards,<br>
Jaco</p>
</body>
</html>