One of the biggest questions in the world of Asterisk is: “How many concurrent channels can be sustained with an Asterisk server?” – while many had tried answering the question, the definitive answer still alludes us. Even the title of this post says “3500 concurrent channels with Asterisk” doesn’t really say much about what really happend. In order to be able to understand what “concurrent channels” really means in the Asterisk world, let us take a look at some tests that were done in the past.
Asterisk as a Signalling Only Switch
This scenario is one of the most common scenarios in the testing world, and relies upon the basic principle of allowing media (RTP) to traverse from one end-point to the other, while Asterisk is out of the loop regarding anything relating to media processing (RTP). Examine the following diagram from one of the publicly available OpenSER manuals:
Direct Media Path between phones via a SIP Proxy
As you can see from the above, the media path is established between our 2 SIP endpoints.
This classic scenario had been tested in multiple cases, with varying codec negotiations, varying server hardware, varying endpoints, varying versions of Asterisk – no matter what the case was, the results were more or less the same. Transnexus had reported being able to sustain over 1,200 concurrent channels in this scenario, which makes perfect sense.
Why does it make sense? very simple, as Asterisk doesn’t manage or mangle RTP packets, Asterisk performs less work and the server also consumes less resources.
Asterisk as a Media Gateway
Another test that people had done numerous times is to utilize Asterisk a Media Gateway. People used it as a SIP to PSTN gateway, SIP to IAX2 gateway, even as a SIP to SIP transcoder gateway. In any case, the performance here varied immensly from one configuration to another, however, they all relied on a simple call routing mechanism of routing calls between endpoints and allowing Asterisk to handle media proxy tasks and/or handle codec translation tasks.
Depending on the tested codec, I’ve seen reports of sustain over 300 concurrent channels of media on a single server, while other claim for around the 140 concurrent channels mark – this again mostly relied on various hardware/software/network configurations – so there is nothing new in there.
These tests tell us nothing
While these tests are really nice in the theoretical plane of thinking, it doesn’t really help us in the design and implementation of an Asterisk system – no matter if it is an IVR system, a PBX system or a time entry phone system for that matter – it simply doesn’t provide that kind of information.
The Amazon EC2 performance test
In my previous post, Rock Solid Clouded Asterisk, I’ve discussed the various mathmatics involved in calculating the RoI factors of utilizing Cloud computing. One thing the article didn’t really tell us, did it really work?
Well, here are some of the test results that we managed to validate:
- Total number of Asterisk based Amazon EC2 instances used: 24
- Total number of concurrent channels sustained per instances (including media and logic): 80
- Average length of call: 45 seconds
- Total number of calls served: 2.84 Million dials
- Test length: approximately 36 hours
According to the above data, each server was required to dial an approximate 3300 dials every hour. So, let’s run the math again:
- 3300 Diales per hour
- 55 Dials per minute
- As each call is an average of 45 seconds, this means that each gateway generates 20 calls
per second, and within 4 seconds fills the 80 channels limit per server.
According to the above numbers that we’ve measured, each of the Amazon EC2 instances used was utilized to about 50% of its CPU power, while consuming a load average of 2.4, which was mostly caused by I/O utilization for SIP and RTP handling.
Conclusion
When asking for the maximum performance of Asterisk, the question is incorrect. The correct question should be: “What is the maximum perfromance of Asterisk, utilizing X as the application layout?” – where X is the key factor for the performance. Asterisk application performance can vary immensly from one application to another, while both appear to be doing the exact same thing.
When asking your consultant or integrator for the top performance, be sure to include your business logic and application logic in the Asterisk server, so that they may be able to better answer your question. Asterisk as Asterisk is just a tools, asking for its performance is like asking how many stakes a butcher’s knife can cut – it’s a question of what kind’a steaks you intend on cutting.
5 Comments
[…] bookmarks tagged concurrent Read my words – 3500 concurrent channels with Aste… saved by 3 others Phillychesse bookmarked on 02/18/09 | […]
Hi! I am trying to setup a high availability asterisk cluster on ec2 to handle 150 concurrent calls and I’m wondering the best way to go about it. Through our earlier conversation and research I recognize that the Asterisk Meetme functionality does not work on ec2 but this is not an important feature to me. The cluster needs to be scalable because although right now I am only planning to accommodate 150 concurrent calls during peak time, I desire to be able to handle at least double that with the addition of a couple of more asterisk machines. It seems like some people have done it using heartbeat but from what I’ve read it seems like that is more for redundancy than high availability. Also I’ve read some articles that seemed to use database replication in which one machine was responsible for keeping the master database and each asterisk node kept a local copy of the database that it read from but did writes to the master (which trickled down to the local dbs) and DUNDI was used in this installation.From a load balancing standpoint is openSer the best option with the dispatcher module?
Here is the ultimate plan: To have an ATA device encode and decode calls using g729. Use openSer to direct traffic and handle registrations. So for instance if someone wanted to make a call from the ATA to the PSTN, OpenSer would help establish the invitation process between the ATA and pstn gateway and would not be included after that. Asterisk would only be used for voicemail and other features for the person on the ATA. I’m not sure if this is even possible put I would like for normal calls (from ATA to ..say someone on the PSTN) to not route their RTP traffic through Asterisk.
I’m sorry if this confusing. I’ve been furiously reading to try to understand but I’m sure I’m not close to being there. I would appreciate any help at all.
Thanks,
Blake McKeeby
Hi Blake,
Sounds like your setup is fairly common from what I can tell. It is true that Heartbeat is mainly used to High-Availability. Load balancing requires the use of either OpenSER (or a similar software) or a vendor Session Border Controller. Bear in mind that the NAT based network environment of Amazon EC2 may pose some issues.
In terms of configurations, there is no single answer here, as it requires a proper analysis of your provisional business model. Feel free to contact me by email and I’ll see how I can assist you on your quest.
If H.323 would suffice you may be interested to know that a single instance of GNUGK easily handles 60,000 call setups per hour with a load average of 0.1, and that’s with the Postgres server on the same machine. That hardware is getting old now: 2GHz AMD64 X2, 2GB DDR RAM and mdraid mirroring across 2 SATA drives.
Hi Stavros,
I’m not sure if you recall, but I’m well versed in GnuGK. Back in 2003 I used GnuGK+FreeRadius+MySQL to traverse over 25 Million minutes a month. I have to admit that the idea of running a cluster of GnuGK systems using Amazon EC2 is interesting, however, the nature of H323 and its incompatibility with NAT and the fact that Amazon EC2 is based on NAT networks, I would say that it poses an interesting issue.
In any case, GnuGK was optimally built to handle call setup requests, as it’s a GateKeeper, very much like a SIP proxy or SIP Session Border Controller, while Asterisk isn’t really built for that kind of function.