[asterisk-dev] Asterisk Performance as a B2BUA]
di-shi at transnexus.com
Thu Jan 24 05:13:01 CST 2008
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.
----- 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%
> The test details are available at http://www.transnexus.com/White%
> Di-Shi Sun
> VoIP Routing, Accounting, Security
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
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
There are still optimizations that can be made to chan_sip; perhaps
there are optimizations that can be made to increase the number of
there is still a lot of work to be done to explore all the bottlenecks
More information about the asterisk-dev