PS. In a NAT'd world, thousands of devices with low re-registration intervals are legion. Getting the database out of that business can literally be a tectonic game-changer in terms of the underlying economics in a service provider environment. It's incredibly wasteful and mostly pointless.
On Fri, Apr 27, 2018 at 02:38:37PM -0400, Alex Balashov wrote: > Another big advantage of DMQ is that it's transported over SIP using a > custom request method (KDMQ). This sets up an opportunity to add > additional infrastructure to deal with routing and managing those > requests intermediately if needed in a large-scale environment. > > DMQ is a great thing, and we owe one to Charles & co. > > On Fri, Apr 27, 2018 at 07:23:51PM +0100, Charles Chance wrote: > > > Hello Joel, > > > > +1 to everything Alex has said. Using DMQ simplifies/flattens the stack and > > allows for a truly decoupled cluster with fewer points of failure. > > > > In production we use DMQ for htable, usrloc, dialog and presence, where > > previously we were using MySQL with Percona - now, performance is vastly > > improved and the admin overhead is greatly reduced. > > > > Disclaimer: I am possibly very slightly biased! > > > > Cheers, > > > > Charles > > > > > > On Fri, 27 Apr 2018 at 16:45, Alex Balashov <[email protected]> > > wrote: > > > > > Hello Joel, > > > > > > Our experience with using DMQ for dialog and usrloc replication has been > > > very positive, and we recommend it wholeheartedly over the crusty > > > database sync-based methods. > > > > > > The primary appeal comes from the fact that the replication is done at a > > > higher level, so there is no need to contend with issues surrounding the > > > degree of two-way coupling that DB-backed modules have. For instance, > > > the dialog module has both "runtime" and "persistent" components to its > > > backing, so while the dialog module can store dialog info in a DB table, > > > it can't store profile info. Replicating dialogs via DMQ allows one to > > > share profile state. > > > > > > And in general, it's a lot more efficient. If you have 3 or 4 > > > registrars, you have a reasonable degree of persistence if you use in > > > memory-only storage for usrloc with DMQ replication. That takes an > > > enormous workload off the database. > > > > > > Databases are for storage; they aren't great for highly ephemeral, > > > short-lived, real-time data, though they're often (mis)used for that > > > purpose: > > > > > > https://en.wikipedia.org/wiki/Database-as-IPC > > > > > > DMQ solves a much-needed gap here in Kamailio, and I hope it is extended > > > to provide transport for other components too. > > > > > > -- Alex > > > > > > On Fri, Apr 27, 2018 at 08:31:56AM -0700, Joel Serrano wrote: > > > > > > > Hi all, > > > > > > > > Just wanted to know what your opinions were on using DMQ modules over > > > > database for things like dialog replication, registrations, etc... > > > > > > > > Is DMQ the "new way to go"? I know that there lots of ways of doing > > > things > > > > with each having pros/cons... But I was wondering... > > > > > > > > What does the community think on this topic? > > > > > > > > Are you guys taking advantage of the DMQ modules or are you still > > > > relying > > > > on database as much as possible? Maybe a combination of both? > > > > > > > > Cheers, > > > > Joel. > > > > > > > _______________________________________________ > > > > Kamailio (SER) - Users Mailing List > > > > [email protected] > > > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > > > > > -- > > > Alex Balashov | Principal | Evariste Systems LLC > > > > > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > > > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > > > > > _______________________________________________ > > > Kamailio (SER) - Users Mailing List > > > [email protected] > > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > > > -- > > Sipcentric Ltd. > > Company registered in England & Wales no. > > 7365592. Registered > > office: Faraday Wharf, Innovation > > Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
