[asterisk-users] Capacity of single instance of Asterisk
BryantZ at zktech.com
Tue Mar 13 10:06:20 CDT 2012
From: "Kevin P. Fleming" <kpfleming at digium.com>
Sent: Tuesday, March 13, 2012 11:02 AM
To: asterisk-users at lists.digium.com
Subject: Re: [asterisk-users] Capacity of single instance of Asterisk
On 03/13/2012 09:43 AM, Amit Patkar | Avhan Technologies Pvt Ltd wrote:
> Thank for your views. Where as no one is ready to share real numbers. I
> looking at benchmarks so that I can plan for resources.
> Since asterisk project is active for so many years, I was expecting some
> published numbers.
You have completely missed the point that other posters have made
already on this list. Let me try to express it another way. Let's say
that you were browsing at an engine manufacturer's website, looking at
V-8 gasoline engines, and you found one that you liked, that you felt
had a good combination of features for your project. If you then
contacted the manufacturer and asked them 'how fast can this engine make
a car travel', what do you think their response would be?
Asterisk is a toolkit; it can be configured an infinite number of ways.
Any performance measurements that are made and published apply *only* to
the specific configuration that was measured; it may or may not be
possible to extrapolate those into other configurations, or higher/lower
There are lots of published numbers of Asterisk being used in various
ways and for different purposes; whether any of them apply to your
specific project is debatable, and relying on them for your project
would carry some level of risk. Whether you are willing to accept that
risk or not is up to you.
In your specific case, as has been mentioned already, it is extremely
unlikely that your proposed hardware would have any trouble with
Asterisk 1.8 handling 2,400 SIP call legs (1,200 bridged calls), with
the same codec being used on both sides. When you add in transcoding,
that will change the system significantly, and depending on the codecs
involved, the hardware may still be able to handle the load. I know from
experiments I did years ago with an 8-core Xeon machine (2nd generation
Xeon, so nowhere near as powerful as modern Xeon cores) that the Digium
G.729 codec (software implementation) could handle over 800 channels
with Asterisk 1.4; I think it's reasonable to expect that given the
hardware you've proposed, transcoding 1,200 channels between G.711 ulaw
and G.729A is likely to be achievable.
Recording, though, is an entirely different matter. Again, since you
haven't provided specifics, let's assume you are going to record the
call legs 'as is' (in their native formats, unmixed). If you had 2,400
G.711 ulaw call legs to record, some simple math says that you'd need be
able to push 150 megabytes per second of data onto your filesystem, on
top of all the 'normal' work that Asterisk is doing. That's rather a
lot, and will require that your filesystem and disk subsystem be
extremely fast and well tuned.
If the call legs were all G.729A, then the amount of data to write would
drop to 18.75 megabytes per second, which is achievable even with
inexpensive SATA disks.
If you want the calls recorded in 'mixed' form (most likely in 16-bit
signed linear PCM audio, since that's the easiest format to use outside
of Asterisk), you'd double the amount of data going into the filesystem
(now 300 megabytes per second) *and* you'd add in the CPU consumption of
having to decode the incoming media streams and mix them. For G.711 ulaw
this is pretty cheap and would likely not be an issue; for G.729A it's
somewhat more expensive, but still might not be a problem given the
amount of CPU capacity you have proposed.
Now do you understand why 'benchmarks' don't provide much value for
something like Asterisk?
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
This is an extremely well stated response.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-users