27 Apr
2018
27 Apr
'18
5:31 p.m.
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.
27 Apr
27 Apr
5:42 p.m.
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
sr-users(a)lists.kamailio.org
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/
8:23 p.m.
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 <abalashov(a)evaristesys.com>
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:
--
Sipcentric Ltd.
Company registered in England & Wales no.
7365592. Registered
office: Faraday Wharf, Innovation
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
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
sr-users(a)lists.kamailio.org
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
8:38 p.m.
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 <abalashov(a)evaristesys.com>
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:
--
Sipcentric Ltd.
Company registered in England & Wales no.
7365592. Registered
office: Faraday Wharf, Innovation
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. 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
sr-users(a)lists.kamailio.org
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
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/
8:49 p.m.
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:
--
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/
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 <abalashov(a)evaristesys.com>
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:
--
Sipcentric Ltd.
Company registered in England & Wales no.
7365592. Registered
office: Faraday Wharf, Innovation
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. 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
sr-users(a)lists.kamailio.org
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
30 Apr
30 Apr
11:13 a.m.
On Fri, Apr 27, 2018 at 8:23 PM, Charles Chance
<charles.chance(a)sipcentric.com> wrote:
[...]
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.
[...]
Hi Charles,
can you provide us with more info on how you configured DMQ between
the different kamailio instances?
We have a scalable dockerized environment and it's difficult to
configure DMQ having dynamic IPs, instances booting up and scaling
down on demand.
Also we've noticed that when a new instance comes up it doesn't sync
old values from the other dialogs and hash tables but gets only new
values from the boot time on.
Kind regards and thanks,
Alex
6:06 p.m.
On Mon, Apr 30, 2018 at 11:13:13AM +0200, Aleksandar Sosic wrote:
We have a scalable dockerized environment and it's
difficult to
configure DMQ having dynamic IPs, instances booting up and scaling
down on demand.
A DNS alias that resolves to multiple entries is a great way to do that:
https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.notification…
https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.multi_notify
although it'd be great if DMQ could exclude the local host from those
notification peers automatically, so that one didn't have to set up
multiple, exclusionary DNS entries for specific instances. Who knows,
maybe it can.
But in principle, such DNS records can be tied to the internal DNS
resolution of a container discovery mechanism, be it Docker's internal
mechanism or something more like Consul.
-- Alex
--
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/
7:01 p.m.
(You guys confirmed what I was thinking when I started the thread.. thank
you all for your replies, they gave me a lot of confidence on DMQ and I'm
already testing it out)
On Mon, Apr 30, 2018 at 9:06 AM, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On Mon, Apr 30, 2018 at 11:13:13AM +0200, Aleksandar
Sosic wrote:
We have a scalable dockerized environment and
it's difficult to
configure DMQ having dynamic IPs, instances booting up and scaling
down on demand.
A DNS alias that resolves to multiple entries is a great way to do that:
https://kamailio.org/docs/modules/5.1.x/modules/dmq.
html#dmq.p.notification_address
https://kamailio.org/docs/modules/5.1.x/modules/dmq.
html#dmq.p.multi_notify
although it'd be great if DMQ could exclude the local host from those
notification peers automatically, so that one didn't have to set up
multiple, exclusionary DNS entries for specific instances. Who knows,
maybe it can.
But in principle, such DNS records can be tied to the internal DNS
resolution of a container discovery mechanism, be it Docker's internal
mechanism or something more like Consul.
-- Alex
--
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
10:13 p.m.
On Mon, 30 Apr 2018 at 17:08, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On Mon, Apr 30, 2018 at 11:13:13AM +0200, Aleksandar
Sosic wrote:
This is how we’re doing it.
We have a scalable dockerized environment and
it's difficult to
configure DMQ having dynamic IPs, instances booting up and scaling
down on demand.
A DNS alias that resolves to multiple entries is a great way to do that:
https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.notification…
https://kamailio.org/docs/modules/5.1.x/modules/dmq.html#dmq.p.multi_notify
although it'd be great if DMQ could exclude the
local host from those
notification peers automatically, so that one didn't have to set up
multiple, exclusionary DNS entries for specific instances. Who knows,
maybe it can.
It should be doing this already. If this is not the case, let me know in a
separate thread and I can take a look.
As for initial syncing of data, htable and dialog modules do not do this
currently, although I actually have it implemented locally in htable and
plan to push it soon to master. Dialog should not be difficult to do the
same.
Cheers,
Charles
--
*Charles Chance*
Managing Director
t. 0330 120 1200 m. 07932 063 891
--
Sipcentric Ltd.
Company registered in England & Wales no.
7365592. Registered
office: Faraday Wharf, Innovation
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
2 May
2 May
4:56 p.m.
Hello all,
Do you expect the DMQ vs database advantages to still hold true even when
considering REDIS as a database (new backend in devel should make this
possible)? Or are these points mainly relevant when it comes to
traditional, persistent storage databases like mySQL? Thanks!
BR,
George
On 27 April 2018 at 21:23, Charles Chance <charles.chance(a)sipcentric.com>
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 <abalashov(a)evaristesys.com>
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:
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
sr-users(a)lists.kamailio.org
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:01 p.m.
The DMQ advantage still holds due to flattening of the stack/seamlessness, and lack of
mediation/marshaling through DB APIs or manual Redis interactions.
On May 2, 2018 10:56:41 AM EDT, George Diamantopoulos <georgediam(a)gmail.com> wrote:
Hello all,
Do you expect the DMQ vs database advantages to still hold true even
when
considering REDIS as a database (new backend in devel should make this
possible)? Or are these points mainly relevant when it comes to
traditional, persistent storage databases like mySQL? Thanks!
BR,
George
On 27 April 2018 at 21:23, Charles Chance
<charles.chance(a)sipcentric.com>
wrote:
Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-- Alex
--
Sent via mobile, please forgive typos and brevity.
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
<abalashov(a)evaristesys.com>
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
Sipcentric Ltd. Company registered in England & Wales no. 7365592. 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
sr-users(a)lists.kamailio.org
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7:36 p.m.
By way of further answer:
The use of a database as an interprocess communication mechanism is
considered an antipattern (the opposite of a "best practice"):
https://en.wikipedia.org/wiki/Anti-pattern#Software_design
https://en.wikipedia.org/wiki/Database-as-IPC
While relational databases perform the worst at this, the fundamental
problem is using the database as a work queue for ephemeral/real-time
data. Simply using a faster, and/or nonrelational database, doesn't
remove the problem, it just makes the setup perform better. It's a
difference of degree, not kind.
Ultimately, databases — including in-memory key-value stores — are for
storage, not for IPC. This doesn't stop them being routinely used as
such by people who do not know how to write IPC mechanisms and
middleware of their own. That's less excusable in an era with lots of
prefabricated options, whether message queues (e.g. AMQP) or distributed
systems closer to the application level (like DMQ).
-- Alex
--
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/
9:12 p.m.
Am Mittwoch, 2. Mai 2018, 19:36:11 CEST schrieb Alex Balashov:
By way of further answer:
The use of a database as an interprocess communication mechanism is
considered an antipattern (the opposite of a "best practice"):
https://en.wikipedia.org/wiki/Anti-pattern#Software_design
https://en.wikipedia.org/wiki/Database-as-IPC
While relational databases perform the worst at this, the fundamental
problem is using the database as a work queue for ephemeral/real-time
data. Simply using a faster, and/or nonrelational database, doesn't
remove the problem, it just makes the setup perform better. It's a
difference of degree, not kind.
Ultimately, databases — including in-memory key-value stores — are for
storage, not for IPC. This doesn't stop them being routinely used as
such by people who do not know how to write IPC mechanisms and
middleware of their own. That's less excusable in an era with lots of
prefabricated options, whether message queues (e.g. AMQP) or distributed
systems closer to the application level (like DMQ).
Hello Alex,
you are right of course regarding the comments about the anti-pattern using databases as
IPC.
But IMHO there are valid use cases for storing a registration in a database, like access
for
third party applications. E.g. you have a front end that shows customer care if a user is
registered or not, and you don't want that this PHP GUI access directly your Kamailio
servers. Or you need to access the registration data in a big java enterprise middle-ware
for user contract status.
But in a smaller or more homogeneous environment its of course easier to synchronize the
registration state with DMQ.
Best regards,
Henning
9:13 p.m.
Henning,
I would agree with that. All depends on your design priorities.
-- Alex
--
Sent via mobile, please forgive typos and brevity.
3 May
3 May
3:07 a.m.
You can have both. What we did is create a designated writer. A kamailio
instance that participates in DMQ but handles no SIP traffic and
periodically writes registrations from memory to a database.
The other nodes work out of memory and load registrations from the writer
node's db on restart.
On Wed, May 2, 2018, 15:14 Alex Balashov <abalashov(a)evaristesys.com> wrote:
Henning,
I would agree with that. All depends on your design priorities.
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
3:10 a.m.
We did that as well.
On May 2, 2018 9:07:53 PM EDT, John Petrini <jpetrini(a)coredial.com> wrote:
You can have both. What we did is create a designated
writer. A
kamailio
instance that participates in DMQ but handles no SIP traffic and
periodically writes registrations from memory to a database.
The other nodes work out of memory and load registrations from the
writer
node's db on restart.
On Wed, May 2, 2018, 15:14 Alex Balashov <abalashov(a)evaristesys.com>
wrote:
> Henning,
>
> I would agree with that. All depends on your design priorities.
>
> -- Alex
>
> --
> Sent via mobile, please forgive typos and brevity.
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- Alex
--
Sent via mobile, please forgive typos and brevity.
12:21 p.m.
Hi Charles,
With regards presence, are you using dmq module with dmq_t_replicate to
replicate publish messages?
On 27/04/18 19:23, 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
1:28 p.m.
Hi,
On Thu, 3 May 2018 at 11:22, Asgaroth <00asgaroth00(a)gmail.com> wrote:
Hi Charles,
With regards presence, are you using dmq module with dmq_t_replicate to
replicate publish messages?
No, recently added integration directly into the presence module:
https://www.kamailio.org/docs/modules/devel/modules/presence.html#presence.…
On 27/04/18 19:23, Charles Chance wrote:
--
*Charles Chance*
Managing Director
t. 0330 120 1200 m. 07932 063 891
--
Sipcentric Ltd.
Company registered in England & Wales no.
7365592. Registered
office: Faraday Wharf, Innovation
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1:39 p.m.
Is that available in stable 5.0.x / 5.1.x or is it only available in
master branch?
On 03/05/18 12:28, Charles Chance wrote:
Hi,
On Thu, 3 May 2018 at 11:22, Asgaroth <00asgaroth00(a)gmail.com
<mailto:00asgaroth00@gmail.com>> wrote:
Hi Charles,
With regards presence, are you using dmq module with
dmq_t_replicate to
replicate publish messages?
No, recently added integration directly into the presence module:
https://www.kamailio.org/docs/modules/devel/modules/presence.html#presence.…
On 27/04/18 19:23, 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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
*Charles Chance*
Managing Director
t. 0330 120 1200 m. 07932 063 891
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
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2:55 p.m.
Only in master I’m afraid due to a DB schema change. The relevant patches
should work fine on 5.1 if you wanted to apply it locally:
https://github.com/kamailio/kamailio/pull/1402
https://github.com/kamailio/kamailio/pull/1435
Cheers,
Charles
On Thu, 3 May 2018 at 12:40, Asgaroth <00asgaroth00(a)gmail.com> wrote:
Is that available in stable 5.0.x / 5.1.x or is it
only available in
master branch?
On 03/05/18 12:28, Charles Chance wrote:
Hi,
On Thu, 3 May 2018 at 11:22, Asgaroth <00asgaroth00(a)gmail.com> wrote:
--
*Charles Chance*
Managing Director
t. 0330 120 1200 m. 07932 063 891
--
Sipcentric Ltd.
Company registered in England & Wales no.
7365592. Registered
office: Faraday Wharf, Innovation
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
Hi Charles,
With regards presence, are you using dmq module with dmq_t_replicate to
replicate publish messages?
No, recently added integration directly into the presence module:
https://www.kamailio.org/docs/modules/devel/modules/presence.html#presence.…
On 27/04/18 19:23, Charles Chance wrote:
--
*Charles Chance*
Managing Director
t. 0330 120 1200 m. 07932 063 891
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
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2190
days inactive
2196
days old
19 comments
8 participants
participants (8)
-
Aleksandar Sosic -
Alex Balashov -
Asgaroth -
Charles Chance -
George Diamantopoulos -
Henning Westerholt -
Joel Serrano -
John Petrini