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

Greger V. Teigre greger at teigre.com
Tue May 31 22:57:11 CEST 2005


I believe this was what Jan sketched out, though he hasn't defined how 
entries should be discarded. Most recently used can be one, most often 
accesed another.
g-)

Alex Vishnev wrote:
> 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
>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers 




More information about the sr-users mailing list