On Mon, Jan 11, 2021 at 7:38 AM Jaco Kroon <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 > > 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
-- _____________________________________________________________________ -- 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
