[asterisk-dev] func_cdr performance issue

[Jaco Kroon]

Hi,

On 2021/01/11 13:47, Joshua C. Colp wrote:
> On Mon, Jan 11, 2021 at 7:38 AM Jaco Kroon <jaco at uls.co.za
> <mailto: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
> <https://wiki.asterisk.org/wiki/display/AST/The+Stasis+Message+Bus>

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).

>  
>
>
>     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.

Thanks for the confirmation.

>  
>
>
>     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.

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.

Kind Regards,
Jaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210111/6ce3818f/attachment.html>