[asterisk-dev] Asterisk Performance as a B2BUA

[Steve Murphy]

On Sat, 2007-11-17 at 07:55 +0800, Di-Shi Sun wrote:
> Hi All,
> 
> We recently performed an indepth performance test on Asterisk V1.4.11
> configured as a SIP B2BUA.
> 
> Asterisk was running on a server with two Xeon 5140, dual core, 2.33
> GHz CPUs and 4 GB of RAM.
> 
> We found that an Asterisk B2BUA on this hardware can manage 1500
> simultaneous calls with no transcoding and 400 simultaneous calls with
> G.711 to G.729 transcoding.
> 
> A summary of the test is available at http://www.transnexus.com/White%
> 20Papers/asterisk_V1-4-11_performance.htm
> 
> The test details are available at http://www.transnexus.com/White%
> 20Papers/Asterisk_Performance_as_a_SIP_B2BUA.pdf
> 
> Regards,
> 
> 
> Di-Shi Sun
> VoIP Routing, Accounting, Security
> www.TransNexus.com

Di-Shi--

I have been working on a branch (asterisk/team/murf/bug11210), in which
I have 
implemented hash tables (and a few other optimizations) almost
everywhere there used to be a loop involved in searching. I left loops
that were not involved in searching alone.

According to my tests on my gutless little test machine, I was only able
to 
increase the number of simultaneous calls by 10% or so; but the changes
did have a profound effect on the speed of call processing... * went
from handling about 
100 incoming calls per second, to around 450. These were extremely
short-duration calls (.1 second), and this exercised the call
setup/teardown parts of the channel driver quite well.

And, I've gotten a report that a user with 5600 peers/users saw config
load/reload times drop from 30 sec to 1 sec.

I was wondering if it might be possible to try your tests again on this
code branch, and see what kind of effects it will have. It's still
experimental code; but I promise to give you top priority if you run
into problems!

There are still optimizations that can be made to chan_sip; perhaps
there are optimizations that can be made to increase the number of
simultaneous calls; 
there is still a lot of work to be done to explore all the bottlenecks
involved.

murf

> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080119/05810adf/attachment-0001.bin