<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2627" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>> Actually, a minute delay would be a bad thing because
replicated<BR>> usrloc records, using t_replicate() would not make it in to
peer SER<BR>> server caches when the server is starting
up. <BR></DIV>
<DIV>Yeah, I forgot about that scheme...</DIV>
<DIV> <BR>> Given this fact, and given the fact that most SER modules do
not hash<BR>> data upon server startup [like group.so, etc, etc] we are
starting to<BR>> see little value in caching usrloc. Our MySQL server is hit
12 times<BR>> for an INVITE message and so complete caching of usrloc is of
minimal<BR>> performace gain. <BR>> <BR>> Anyhow,
we're not in process of modifying SER so that:<BR>> <BR>> * when ser
starts up usrloc is "lazy-loaded"<BR>> * if a usrloc record is looked up in
cache and is __NOT__ found, then<BR>> MySQL will be queried. If found in
MySQL then the usrloc record will<BR>> be put in to cache for future
lookups <BR>> <BR>> By doing these two things we should not have a
problem we excessively<BR>> large subscriber bases. <BR>> <BR>>
Thoughts?</DIV>
<DIV> </DIV>
<DIV>Makes sense. This is how Berkeley DB and many other DBs work.
In fact, the best would be to build an abstraction cache layer around all the
query functions that have data in the DB. This way you would get the optimum
performance/scalability.</DIV>
<DIV> </DIV>
<DIV> However, there is one more thing: You need to decide on
an algorithm for selecting a usrloc record to replace when the cache is
full. Do you store extra info in memory for each usrloc to make the right
decision (ex. based on the number of lookups).</DIV>
<DIV>Also, what to do when you are storing a new location with save: Do you put
it in the cache as well? Today this happens automatically. As you have
continous registrations, you will fill up the cache with registered clients (and
push out the ones having been called). What you really want is to keep the
user locations you need (those required by lookup) in the cache. So I
would suggest that in save(), you only write to the DB (and of course update the
record if its in the cache) and that lookup() is the function that will control
the activation and replacement of the records in the cache. </DIV>
<DIV> </DIV>
<DIV>I think this approach to caching is of interest also to those who do not
have a mysql cluster, but do regular replication, for example to reduce start-up
time. I believe an implementation may get pretty involved (in terms of
important functions you need to touch). However, I cannot see that you
will need to touch the core. </DIV>
<DIV> </DIV>
<DIV>g-)</DIV>
<DIV><BR>> Paul<BR>> <BR>> <BR>> On 5/29/05, Greger V. Teigre
<greger@teigre.com> wrote:<BR>> Interesting discussion. I believe
most large-scale deployments (there<BR>> aren't really that many...) divide
the user base across several<BR>> servers. I <BR>> believe they use 20K
users is a "good number" per server. So, one ser<BR>> having to load
that many records, is only if you have a cluster with<BR>> no <BR>> server
divide. Loading all the contacts into memory is impossible to<BR>>
scale, <BR>> at one point it will take too long time and take too much
memory. <BR>> So, a <BR>> better architecture *for such a deployment
scenario* would be a cache<BR>> of <BR>> some size and then a lookup of
records in DB if not present in cache.<BR>> Loading 330 records per second,
you can load about 20,000 contacts in<BR>> a <BR>> minute, which probably
is ok.<BR>> g-)<BR>> <BR>> Zeus Ng wrote:<BR>>> See inline
comment.<BR>>> <BR>>>> Thanks for the info. I did change that
config.h define and<BR>>>> now it works well.<BR>>> <BR>>>
Great to hear that the little change solve your problem.<BR>>>
<BR>>>> <BR>>>> My newest problem is the ser start time. In my
very<BR>>>> non-scientific test it took ser about 25 minutes before
it<BR>>>> began serving requests because it was loading usrloc
information.<BR>>>> <BR>>>> That was using 500000 records in
the location table. The<BR>>>> MySQL server was running on the same box
as SER, which is<BR>>>> also my workstation, so stuff like Firefox, X,
etc, were in use.<BR>>>> <BR>>>> But this does bring up an
interesting problem namely - how<BR>>>> can ser service SIP clients
while loading large number of<BR>>>> usrloc records? I'm kind of
thinking that this could be a big<BR>>> <BR>>> No, you can't. In
fact, you will experience a temporary slow down<BR>>> when a hugh number
of UA is un-registering because the table was<BR>>> locked during that
period of time. I once use sipsak to register 5000<BR>>> users in 15s.
When they all expired about the same time, SER hang for<BR>>> a while for
locking the table to release the record from memory.<BR>>> <BR>>>
<BR>>>> problem. When dealing with massive user bases there is
no<BR>>>> such thing as a "quick restart".<BR>>> <BR>>>
Well, that's the trade-off of memory base db. You need to balance
the<BR>>> startup time verse runtime performance.<BR>>>
<BR>>>> <BR>>>> We do have LVS fully "sip-aware" so we are
doing true UDP<BR>>>> load balancing based on the Call-ID header, but
this is still<BR>>>> a problem [potentially] with replication ucontact
records<BR>>>> while the server is starting up.<BR>>>>
<BR>>>> I wonder if it is possible to modify the behaviour of
usrloc<BR>>>> so that it loads in the background while ser is
processing<BR>>>> SIP messages. And when lookup("location") is
executed, usrloc<BR>>>> searching the the ser cache and then MySQL if
no hit is found<BR>>>> in cache -- or something like that.<BR>>>
<BR>>> This triggers me to bring up the common question asked on this
list<BR>>> before. Can SER use just MySQL for usrloc? A similar concept
has been<BR>>> done on the speeddial module. It would help load
distribution, faster<BR>>> startup time and better redundancy. Of course,
slower lookup as<BR>>> tradeoff.<BR>>> <BR>>> I once consider
replacing the build-in memory base DB with MySQL<BR>>> memory db. However,
that idea was dropped due to time constrain and<BR>>> compatability
(postgresql) issue.<BR>>> <BR>>>> <BR>>>> Can anyone on
serusers give some tips as to how to get ser to<BR>>>> load usrloc
entries optimized? I know the usual stuff like<BR>>>> faster MySQL
disks, faster network connection, dedicated app<BR>>>> servers, etc,
etc. But I'm looking for ser and/or MySQL<BR>>>> tweaking
hacks.<BR>>> <BR>>> Good luck on your search.<BR>>>
<BR>>> <BR>>>> <BR>>>> Regards,<BR>>>>
Paul<BR>>>> <BR>>>> <BR>>> <BR>>>
_______________________________________________<BR>>> Serusers mailing
list<BR>>> serusers@lists.iptel.org<BR>>>
http://lists.iptel.org/mailman/listinfo/serusers</DIV></BODY></HTML>