We have used in production Asterisk 1.4 to do 3,000 concurrent calls at about 80 CPS without media going through the system. This is on a vmware ESXi server. The server is a Dell R610 with 2 X5670 (6 cores each at 2.93 GHz so 12 physical, 24 logical cores). Each vm gets 2 cores and 2 GB of RAM. We put 3 of these VMs on the physical server with no issues. The CPU usage above 3,000 channels starts to get out of hand. These were all ulaw, no transcoding using directmedia=yes and canreinvite=yes<br>
<br>We tested on Asterisk 1.6 with the same sort of configuration. Asterisk 1.6 could not get above 1000 reliably. Even though it was configured to not be in the media path, it would allocate a timer for each call which would saturate the iowait on the VM. I verified that the VM wasn't processing media.<br>
<br>We did not test on 1.8. We kept 1.4 up to date as possible and have moved to an OpenSIPS routing platform instead to handle higher calls per second.<br><br>Regards,<br>Jared Geiger<br><br><div class="gmail_quote">On Thu, Feb 9, 2012 at 11:06 AM, Stefan Schmidt <span dir="ltr"><<a href="mailto:sst@sil.at">sst@sil.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 09.02.12 16:45, schrieb Patrick Lists:<br>
<div class="im">> Iirc a long time ago there was a discussion about load testing by<br>
> playing MoH was not a realistic test. Something about all MoH music<br>
> getting streamed synchronized so basically Asterisk only has to stream<br>
> one file and sorta multiplex that single output to all the established<br>
> calls (legs).<br>
<br>
</div>this load tests are mostly about sip signal handling and not so much<br>
about rtp streaming but this moh class which i use had 100 files and<br>
random set to yes, so its atleast not soo bad.<br>
<div class="im"><br>
> [snip]<br>
><br>
>> btw my normal production machines which are just the same virtual<br>
>> machines like this test system. i also had 330 concurrent calls, some<br>
>> with transcoding, many database lookups, musiconhold, pickup ... and the<br>
>> sysload was around 1.0 ;)<br>
><br>
> The difference (13500 with MoH versus 330 with a real dialplan) shows<br>
> that it makes sense to mimic your dialplan in your test scenario as much<br>
> as possible to see how far you can realistically push the box and still<br>
> keep things stable and sound quality good.<br>
<br>
</div>This 330 concurrent calls was only the highest value which i had on a<br>
normal production system and its really hard to build a test setup which<br>
presents a system with 4000 sip peer doing some calls.<br>
<br>
but the sound quality was still good even with 10000 calls in my tests.<br>
<br>
> Regards,<br>
> Patrick<br>
><br>
<br>
best regards<br>
<font color="#888888"><br>
stefan<br>
</font><div><div></div><div class="h5"><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br>