[asterisk-users] Capacity of single instance of Asterisk

[Bryant Zimmerman]

----------------------------------------
 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 
am
> 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 
capacities.

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

----------------------------------------------------------------------------
----------
Kevin

This is an extremely well stated response. 

Bryant

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120313/bd147276/attachment.htm>