On 5/29/05, Greger V. Teigre <greger@teigre.com> wrote:

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@iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers