I’m migrating from an ancient asterisk 13 setup. It’s currently handling 100 calls / 200 channels fine on a 2c4t CPU, mainly doing a short announcement and then bridging two peers without direct media. Some recording as well but the bulk of it is just bridging calls and setting up new ones at around 0.2cps. Load is steadily around 0.5 at these levels.
I’ve set up a similar build on a fresh Asterisk 22.6, with the only real difference (apart from the 10y jump in asterisk versions) being a move to pjsip.
I made sure that calls connect via commonly supported media so no transcoding occurs even though RTP passes through asterisk. Now this is a smaller server, 1c2t, but running 100 calls under these circumstances basically blows it up. Pinning cpu close to 100% and load at 20++
50 calls is obviously better, but still at a load way over 1.
I wasn’t expecting miracles but given the optimal circumstances I think this feels unexpectedly low. I know system requirements are a complex topic but considering my very basic use case, does anyone have any input on what i could expect?
Are there any commonly missed optimizations to think about?
Is there any internal monitoring to check what’s causing the load? For example if it’s for some reason transcoding alaw→alaw or something like that.
That doesn’t match what I’ve seen other people get or my own testing, so it certainly sounds as though something is going on. There is no internal monitoring, I’m not even sure if there could be in a single process application. The easiest option would be to start with verifying all the assumptions.
Use “core show channel” to look at the channels and confirm codecs in use.
Compare console output for dialplan execution between old and new to truly verify they’re the same.
Reduce the scenario to further isolate where usage may be coming from.
Verify the underlying system is healthy. I’ve seen cases where such a result occurs when recording if the underlying storage is having issues.
Confirm that the usage can be reproduced on a second system/instance.
You also didn’t state how many calls per second, which can have an impact and alter things.
I’ve now reproduced this with just a simple Dial() as well. I do add a sip header in a pre-dial context, but no playback or anything else really. So dialplan does differ, but to the benefit of the tested system which is even worse.
Both of these are virtual servers, and i’ve tested running on the same host with no difference. It’s now running on a more modern host but you’re very similar. I’ve set this up from scratch (Debian 13, freshly compiled asterisk) with no difference. The system is completely clean and up to date, only running asterisk except for a light monitoring agent which is common to both servers.
I’m compiling with everything default except i add in mp3 support, though i don’t use it.
My test is set to run 50 parallel 10 minute calls so the CPS is basically 0. For the existing system it’s around the same, but probably around double that since calls are rarely as long as 10 minutes and there’s also a few busy/missed calls in the real system.
Sysbench gives a reasonable result and for example asterisk compile time was normal from my experience.
Very odd! Thanks for the help so far though @jcolp i really appreciate it.
In your experience, what’s the expected amount of parallel calls in this setup? Are we talking 50, 200, 3000? I’ve had a really hard time finding any public information about this except for a few posts from 15+ years ago talking about extremely large numbers.
More than 100. Less than 1000. That’s the best I can do. Noone will give anything further because even with such a scenario there are still factors at play that alter things. The specific CPU can alter the result, which virtualization is in use is a factor, and more.
So unfortunately I don’t know why under your arrangement it’s behaving as such.
100-1000 is still a pretty decent estimate. Any experience with how it scales with increased core count? Is it more or less 1:1 up to reasonable levels or are there any known asterisk-internal limitations on parallelization? Of course assuming that RAM or disk is not a limiting factor.
I COULD just crank this up to 16c32t if i can’t figure out what else is causing this but obviously i’d prefer not to. Actually that would be an interesting test for my troubleshooting here..
I won’t say it is 1:1 because there are aspects that are inherently single threaded and eventually become a bottleneck depending on usage patterns (manager, CDR, CEL come to mind). Most things, including media flow, inherently use multiple threads so should be scheduled across multiple cores by the kernel.
Looks like i was just pushing the limit of a 1c2t system. 2 threads hit the limit very quickly but 4c8t handled about 400+ calls at 0.5 load until my call generator croaked.
My wild guess would be that one of those single threaded things caused things to back up, but with 8 threads it’s more likely to get attention quicker. But who knows. At least i feel like i’m at a reasonable performance/cost level now
