So, you are interested to know – how many calls can a server running on Amazon EC2 can actually handle? Well, the actual number is…
No, I’m not going to tell just like that – the number doesn’t mean anything. It means nothing, simply because the number that we reached was applicable to our application – your numbers may vary. So, before we go about spitting numbers and crunching them down, let’s talk about a few Asterisk concepts that will allow you to optimize your configuration.

Understand your application

Many Asterisk application/platform developers tend to think of Asterisk as a closed API set. That means that it is what it is, and if parts of it are just too big – can’t do much about it. Well, that is the worst mistake one can make. Asterisk is actually quite far from that, enabling the developer a fine grain control over the Asterisk boiler plate. And when I say “The Asterisk Boiler Plate”, I’m not referring to the actual code that you write, I’m actually referring to the modules that are loaded by Asterisk.  Here’s a funky question, how many modules does Asterisk actually load? well, the answer varies according to your version. However, just to give a rough idea, version 11.2.0 loads over 190 different modules!

Now, in some cases, most of these modules can be completely disregarded. For example, if you are building a SIP to PSTN gateway, there is no use for app_queue (Queuing) or res_musiconhold (MusicOnHold), simply they have no place in such an application environment. Don’t believe me? here is just a small example of how your resources are being consumed without a need to. By default, Asterisk will load all available codecs, in a normal installation of Asterisk 11.2 that will include the following:

codec_a_mu.so  codec_adpcm.so  codec_alaw.so  codec_g722.so  codec_g726.so  codec_gsm.so  codec_ilbc.so  codec_lpc10.so  codec_resample.so  codec_ulaw.so

Now, in 99% of cases, you can disable the following codecs without causing any issue to with the system functionality:

codec_adpcm.so  codec_g726.so  codec_ilbc.so  codec_lpc10.so

Now, will that affect your system? well, we’re removing 40% of the codecs being loaded. If your system is purely a PSTN system, or operates with a single codec, you can remove 90% of the codecs and leave a single one – that will reduce memory consumption and also reduce other codec related operations, simply because the list is shorter.

By now you’re saying: “What a load of bull! That doesn’t have any proper affect on the system.” – On small scale systems, yes, you are correct. On high volume systems, that can be the difference between 600 concurrent calls and 660 concurrent calls. Imagine, that putting 6 lines of configuration will improve your system by 10%. If you think that ain’t worth while – I don’t know what is.

Let’s talk numbers

In order to facilitate a stress test, we’ll be using HP Sipp utility – with a receiver and a transmitter. All hosts are operating on Amazon EC2 and we’ve taken care to make sure that both the tested instance and the sipp servers are operating utilizing the same exact instance specification. The reason is simple, we want to neutralize as many as possible none-linear/none-equivalent scenarios.

Test Case: M1.Large Instance with 180 Concurrent Calls at 3 CPS

Concurrent Calls and Channels Graph

Load Graph

** A distinct correlation can be observed between call initiation/termination and spikes in the load average.

The interesting part here is that the observed load average exceeded 28 at peek points – calculated according to the 1 Minute load average score.

Now, let’s view the same test, using an M1.X-Large Instance.

Test Case: M1.X-Large Instance with 180 Concurrent Calls at 3 CPS

Concurrent Calls and Channels Graph

Load Graph

** A distinct correlation can be observed between call initiation/termination and spikes in the load average.

The interesting part here is that the observed load average topped at 3.8 at peek points – calculated according to the 1 Minute load average score.

Interim Conclusion

If you are using Asterisk in Amazon and are looking for optimal cost/performance ratio – use an M1.X-Large Instance. Stay tuned for more information on this subject, specifically – what happens when we start ramping up the CPS and the numbers of channels/calls per server.