[asterisk-dev] func_cdr performance issue

[Joshua C. Colp]

On Mon, Jan 11, 2021 at 7:38 AM Jaco Kroon <jaco at uls.co.za> wrote:

> Hi All,
>
> I am very much new to the way in which statis functions.  Is there
> documentation somewhere around the design of this I should be looking at?
>

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.

[1] https://wiki.asterisk.org/wiki/display/AST/The+Stasis+Message+Bus


>
> Our primary issue is that both cdr_read and cdr_write in func/func_cdr.c
> gets very slow (up to four seconds, sporadically).  We're using cdr_odbc
> back-end.
>
> We suspect after looking into the code on func_cdr side that this is due
> to stasis basically sending a message via statis to the cdr engine, and
> then getting delayed due to the SQL process sometimes being slow on
> COMMIT phase of transactions.
>

If not using batching then certainly possible.


>
> I'm thinking of a few possible things that can be done here on the
> asterisk (without having checked whether this may be the case already):
>
> 1.  Switch to batched processing (which hopefully posts multiple
> transactions in a single transaction).
> 2.  Decouple finalization of CDRs from the main CDR thread.
> 3.  Semi batch process where if (and only if) CDRs batch up they're
> batch processed into a single transaction (ie, grab all outstanding,
> post them, reply success to all).
>
> Happy to put in the work, would just like to understand better as to how
> this works so that I don't lay down a fair amount of work for little to
> no gain at all.
>
> From a hardware side we're also busy looking into upgrades w.r.t. disks
> that may help (one consideration is to just add a small NVMe just for
> the SQL database).  Just to be clear we're not just attacking this from
> one front.
>

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.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210111/51dd12ca/attachment.html>