[asterisk-dev] Asterisk Performance as a B2BUA]

[Di-Shi Sun]

Hi Steve,

Thank you for your interest in my Asterisk Performance test. I would like to
test your Asterisk branch, but my work schedule is full for the next several
months. In addition, I would need to schedule dedicated use of the
TransNexus network test bed for up to two weeks to properly test your
software. So this is not a project I can do in my free time, It must be
scheduled as an TransNexus engineering project. I suggest you contact
jim.dalton @ transnexus.com and ask him to consider adding this project to
the TransNexus engineering work schedule.
Regards,

Di-Shi Sun.

----- Original Message ----- 
From: "Steve Murphy" <murf at digium.com>
To: "Di-Shi Sun" <di-shi at transnexus.com>
Sent: Thursday, January 24, 2008 1:50 PM
Subject: [Fwd: Re: [asterisk-dev] Asterisk Performance as a B2BUA]


-------- Forwarded Message --------
From: Steve Murphy <murf at parsetree.com>
Reply-To: murf at parsetree.com
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Subject: Re: [asterisk-dev] Asterisk Performance as a B2BUA
Date: Sat, 19 Jan 2008 09:48:26 -0700

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

>
-- 
Steve Murphy
Software Developer
Digium