[Serusers] SER usrloc caching, was: SER Reports "out of memory"

[Alex Vishnev]

All,

Not sure if this was discussed before, however have you considered MRU cache
implementation. I don't see a reason why the entire userloc needs to be
cached. MRU cache is allocated once during initialization. The size can be
driven via user defined parameter or be statically set to maximum shared
memory segment configured in the system. MRU will be populated over time and
not at once when the system initializes. Therefore, initial startup time
will be short, however a number of incoming requests will need to perform db
queries to retrieve the information and cache it. Comments?

Alex
-----Original Message-----
From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
Behalf Of Zeus Ng
Sent: Tuesday, May 31, 2005 5:49 AM
To: 'Greger V. Teigre'; 'Java Rockx'
Cc: 'serusers'
Subject: RE: [Serusers] SER usrloc caching, was: SER Reports "out of memory"

If implemented properly, usrloc cache will no doubt help scaling SER. My
arguments mainly focus on the DB RW issue. People can decide if pure DB
usrloc is best for them or not. See inline for comments.

> -----Original Message-----

> > If we are to use pure DB only usrloc. That problem will not happen.
> 
> Yes, I believe this is the same problem Karl pointed out? In
> itself it poses 
> an issue, but I think the broader scalability impact is more 
> important.
> 

For me, integrity is much more important than scalability.

> > a UA does a REGISTER request every 5 minutes. The REGISTER 
> request will
> > always behave the same.
> 
> Well, if the cached usrloc is the same as in the REGISTER 
> request, you don't 
> need to write, do you? This should have a huge impact on the 
> number of 
> necessary writes as without a cache, you must write every time.
> 

How about expire time? Even though contact and receive IP are the same,
expire time will almost always be different. You can't ignore that, can you?
Also, if a user has two UA and they register to two different SER instances,
how are we going to sync the cache without writing to DB. 

> > For other requests, there is always a DB read within
> > that 5 minutes interval to populate the cache. Only subsequence 
> > requests
> > go
> > through the cache. You may have a difference call patten 
> but I find rarely
> > two INVITEs to the same UA within 5 minutes interval. After that 5 
> > minutes,
> > the cache becomes invalid and a DB read is required. Using 
> cache saves
> > nothing on DB read here. (Obviously you can argue about longer time 
> > between
> > REGISTER request or contact rarely change with hardphone 
> but the same
> > principle applies)
> 
> I'm not sure I understand. The point here is to look at the 
> lifetime of the 
> usrloc, which arguably is (in most cases) far longer than 
> five minutes. I 
> don't follow you in that the cache is invalid after five minutes?!
> 

The life time of UA and it's contact IP may be very long but the life time
of a register request is limited. The 5 minutes is just an example to
illustrate that once that register expired, the record should not be trust
anymore. Only the new register request, with new expire time should be used.
This is what I mean invalid cache.


> > Besides, I have good experience with MySQL caching
> > results. So, DB lookup on every SIP request with proper DB 
> tunning can 
> > achieve similar result.
> 
> That IS a good point.  However, most of the overhead is not 
> in the actual 
> lookup, but in the call to mysql.  I'm not sure what that 
> overhead is, if it 

On local DB server, the overhead is minimal. Unlike PHP, SER opens the
connection at start up and close it at shutdown. Only the request and result
go through UNIX socket for each query. This reduce the overhead of connect
and disconnect which could be heavy. With remote DB, the over head is TCP.
By using MySQL replication, SER can query local DB and leave the TCP
overhead to MySQL itself. Going via slow WAN link is another issue.

> is very low, you're point hits the "let each system do what 
> it's best at..." 

More or less.

Zeus

_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers