Ultimately a standard test suite like the one so helpfully published in this thread would benchmark the baseline config, then the transcoding config, as this one did. But for each of the combinations of the various codecs. Then a benchmark adding each of various options, like conferencing, recording, etc. That grid would be repeated on each of directly comparable HW configs, like a single CPU with single core at x-GHz, multiple of those CPUs, the same benchmarks repeated for single/multiple multicore CPUs, each at increasing GHz.
That 3D stack of benchmark data could be crunched to find the linear (or other simple formula) ranges for scaling Asterisk capacity for different featuresets, and where they are nonlinear or truly complex as featuresets interact. A proper analysis could report basic units of capacity that might be interchanged (if not too complexly interrelated) like "adding recording to a call means dropping 10 2-party calls or 5 conference legs". That's the kind of benchmarking that I'd expect Digium to do. They probably have already done at least a limited subset, but haven't published any. In fact they decline to engage publicly in such a project at all, saying it's too hard. But such benchmarking, to some degree of completeness, isn't just a basic requirement for capacity planning in deploying networks. It's also a guide to prioritizing work optimizing the Asterisk code that's being benchmarked. At the very least I'd like to see some numbers that show exactly at which scales adding scaling features like SER, RTPproxy, and even DUNDi return extra capacity in exchange for their extra overhead, and the actual Asterisk capacity ceilings at which they are necessary. Those kinds of benchmarks are actually a perfect role for the Asterisk community to collaborate on and share. Once this thread in -biz settles down, I'll see if I can get some interest in the -users list. If someone else who can actually lead a project by setting up a testing config wants to beat me to it, please be my guest. On Sat, 2007-11-17 at 16:33 +0000, Chris Bagnall wrote: > > 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. > > Many thanks for the testing done so far. Hopefully it'll be of considerable > use to the Asterisk community. > > A possible future test: > > What'd be very interesting to see is how Asterisk scales as hardware changes. > For example, by what percentage do the call completion figures increase by > switching to quad-core CPUs? Is it better to have slower quad-core chips, or > faster dual-core chips? > > Looking at the results, memory usage is fairly low, so one could reasonably > deduce that 2GB RAM would be perfectly sufficient. Given that scenario, it'd > be great to have some comparisons with different system specs to achieve the > most "useful" system spec for a given budget. > > Regards, > > Chris -- (C) Matthew Rubenstein _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz