<div dir="ltr"><div dir="ltr">On Mon, Jan 11, 2021 at 7:38 AM Jaco Kroon <<a href="mailto:jaco@uls.co.za">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">https://wiki.asterisk.org/wiki/display/AST/The+Stasis+Message+Bus</a></div><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 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><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><div><font color="#073763">Joshua C. Colp</font></div><div><font color="#073763">Asterisk Technical Lead</font></div><div><font color="#073763">Sangoma Technologies</font></div><div><font color="#073763">Check us out at <a href="http://www.sangoma.com/" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org/" target="_blank">www.asterisk.org</a></font></div></div></div></div></div></div></div></div></div></div></div></div>