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(a)iptel.org [mailto:serusers-bounces@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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers