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: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
