29 May
2005
29 May
'05
11:28 a.m.
Interesting discussion. I believe most large-scale deployments (there
aren't really that many...) divide the user base across several servers. I
believe they use 20K users is a "good number" per server. So, one ser
having to load that many records, is only if you have a cluster with no
server divide. Loading all the contacts into memory is impossible to scale,
at one point it will take too long time and take too much memory. So, a
better architecture *for such a deployment scenario* would be a cache of
some size and then a lookup of records in DB if not present in cache.
Loading 330 records per second, you can load about 20,000 contacts in a
minute, which probably is ok.
g-)
Zeus Ng wrote:
See inline comment.
Thanks for the info. I did change that config.h
define and
now it works well.
Great to hear that the little change solve your problem.
My newest problem is the ser start time. In my very
non-scientific test it took ser about 25 minutes before it
began serving requests because it was loading usrloc information.
That was using 500000 records in the location table. The
MySQL server was running on the same box as SER, which is
also my workstation, so stuff like Firefox, X, etc, were in use.
But this does bring up an interesting problem namely - how
can ser service SIP clients while loading large number of
usrloc records? I'm kind of thinking that this could be a big
No, you can't. In fact, you will experience a temporary slow down
when a hugh number of UA is un-registering because the table was
locked during that period of time. I once use sipsak to register 5000
users in 15s. When they all expired about the same time, SER hang for
a while for locking the table to release the record from memory.
problem. When dealing with massive user bases
there is no
such thing as a "quick restart".
Well, that's the trade-off of memory base db. You need to balance the
startup time verse runtime performance.
We do have LVS fully "sip-aware" so we are doing true UDP
load balancing based on the Call-ID header, but this is still
a problem [potentially] with replication ucontact records
while the server is starting up.
I wonder if it is possible to modify the behaviour of usrloc
so that it loads in the background while ser is processing
SIP messages. And when lookup("location") is executed, usrloc
searching the the ser cache and then MySQL if no hit is found
in cache -- or something like that.
This triggers me to bring up the common question asked on this list
before. Can SER use just MySQL for usrloc? A similar concept has been
done on the speeddial module. It would help load distribution, faster
startup time and better redundancy. Of course, slower lookup as
tradeoff.
I once consider replacing the build-in memory base DB with MySQL
memory db. However, that idea was dropped due to time constrain and
compatability (postgresql) issue.
Can anyone on serusers give some tips as to how to get ser to
load usrloc entries optimized? I know the usual stuff like
faster MySQL disks, faster network connection, dedicated app
servers, etc, etc. But I'm looking for ser and/or MySQL
tweaking hacks.
Good luck on your search.
Regards,
Paul
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers