[asterisk-dev] [Code Review] Rate limit astdb->sync() calls

[Stefan Schmidt]

Am 09.09.10 04:28, schrieb Russell Bryant:
> 
> 
> ----- Original Message -----
>> On Wed, Sep 8, 2010 at 6:33 PM, Russell Bryant <russell at digium.com>
>> wrote:
>>> Thanks for the feedback, guys! I'll get this merged sometime
>>> tomorrow most likely. Also thanks to Stefan Schmidt for the great
>>> performance testing and analysis he has been doing lately! Some
>>> great changes are going to come out of this effort.
>>>
>> +1 for that! While I don't fully understand all the technical
>> discussions going on about astdb, it would be great to see Stefan's
>> release the code for his testing tool. I would be very interested in
>> seeing how it works.
> 
> While the most recent results have been specific to astdb, the more important numbers are the effects on SIP registration performance as a result of the changes.  That's how we got into astdb, since it was identified as one of the bottlenecks when doing SIP registration load testing.  I'm not sure how Stefan's test is built, but doing that via SIPp is pretty easy (at least as far as SIPp goes).
> 
my test setup is just simple ;)

i have two servers connected both to one switch (cause of the bandwith
which reach sometimes 70mbit).
both are patched the same way to ensure the sip power.

on Server A i have 20.000 rows of register user00000 (counting up) to
server B.
on Server B i have a sip.conf.test file with 20.000 peers from user00000
to user19999 with qualify=yes.

i first start server b, then start server a and you will see how fast
sip handling could be.
Server A sends a register to Server B. If the 200 ok is received on
server A, it will register the next user.

without this patch asterisk get out of sync to read and send package,
which causes user to get unreachable (sending out more options package,
still not read) and so everything goes down until every single user is
unreachable. This was the starting point for my work, cause this happens
to my production system after i upgrade from 1.2.40 to 1.6.2.

with 1.6.2.10 the point of death occurs around 8k peers registered.
with this patch it could handle around 15k peers.
with the patch i will put on reviewboard today i hope, i can run through
all 20k peers without a problem. 20k peers with qualify=yes would cause
a load of 0,07 on my system, sending around 350 to 400 sip packets per
second and around 2 mbit of bandwith.


i also use sipp to test subscriptions and calls but the register and
keep alive thing is just done by another asterisk server.

if i had some time today, i will put the testdb app i have written into
my svn branch and also the scripts to generate the sip.conf.test file
and the 20k of register rows.

best regards

steve