[Serusers] Replication problem

[Greger V. Teigre]

Andreas Granig wrote:
> Greger V. Teigre wrote:
>> :-) Jan participated in a discussion on serusers on a new cache
>> system where all locations where not loaded at start-up, but rather
>> at need.
>
> Well, I just read the thread at
> http://lists.iptel.org/pipermail/serusers/2005-May/019867.html and for
> me as a guy who wants to run a scalabe system with a minimum of
> afford and as soon as possible, one question comes up: is it really
> worth the efford to implement such a caching system?

I see your point. However, SER has many different uses and many different 
deployment scenarios. In some scenarios the focus is on high through-put of 
20K users (who are divided across registrars), DNS SRV is used, and Linux HA 
is used for failover.  Relying on a database lookup for every single 
lookup("location") will reduce performance quite a lot.

> Don't understand me wrong, I'm sure there are a lot of people who
> benefit from this caching mechanism in terms of performance, but my
> experience with this is, well, very bad, when using it in a bigger
> environment.

Again, I think it depends on your setup. The setup mentioned above does not 
use DB replication, but separate databases and a path type implementation 
for routing between Registrars for incoming INVITEs.

> For me (and I think a lot of other people, like Paul, who mentioned it
> too in the above thread) the performance won due to the cache lookup
> is so minimal in combination with my 10-15 other mysql queries and
> 1-2 enum queries per call, that I really don't care, especially when
> thinking about the advantages of a consistend location table in the
> backend DB:

This I don't understand either. If you do user preferece lookup, it's for 
the first INVITE, lookup("location") is done for far more messages than just 
the first INVITE. And then you have nathelper's ping every 10-30 seconds...

> No need to replicate on SIP level anymore (and there's no really
> usable mechanism for that for more than two SER nodes), no need to
> distribute other contacts like aliases to every single SER node using
> a remote fifo hack, the need of much less memory, much faster startup
> time and so on, and that all for just a few more milliseconds of
> latency.
> So IMHO the option of disabling the cache absolutely makes sense *in
> some circumstances*, like large scale systems.

Yes, I agree. It would be interesting to run a test on a such system to see 
the actual performance impact.
g-)