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