Hi, On 2021/01/11 13:47, Joshua C. Colp wrote: > On Mon, Jan 11, 2021 at 7:38 AM Jaco Kroon <j...@uls.co.za > <mailto:j...@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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
