I know that this post really belongs on the Asterisk Community Forums but since we are building this on FreePBX, I am trying my luck here first.
FreePBX 15. Asterisk 18.6.0.
8 GB Ram, 500GB SSD, CPU Info:
[root@client1 ~]# lscpu | egrep 'Model name|Socket|Thread|NUMA|CPU\(s\)'
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 2
Socket(s): 1
NUMA node(s): 1
Model name: Intel(R) Xeon(R) CPU E5-2698 v4 @ 2.20GHz
NUMA node0 CPU(s): 0,1
We built a NodeJS ARI app that plays certain audio file generated, and cached so we can reuse it, via Google TTS based on the caller’s DTMF input.
We are stress testing this app and when we hit ~30 concurrent calls, the CPU reaches 100% which is of course affecting the call quality.
So we built a couple of generic IVRs which is using the Background() application and CPU reaches 100% only when we have ~300 concurrent calls running through these set of IVRs.
Looking at htop I see that the ari.js app uses 12% CPU at peak and Asterisk is the one that is eating CPU.
So my question here is. What would cause Asterisk to behave like that when sending calls to ARI? Is there a way to debug/troubleshoot this?
There isn’t really an answer, Asterisk debug logs may provide insight but otherwise it’s generally looking at everything - code, channels (for example codecs in use), and other things.
What debug level should I enable? Right now I have Debug level set at 3 and I see the following logs: https://pastebin.freepbx.org/view/0cb285a8 (raw version)
I did remove tho the AMI events which did not seem relevant.
I did notice tho that we are not handling properly the stopping of playback once DTMF was received. We are working on fixing it.
Playing '/var/lib/asterisk/sounds/mt_schedules/57adb8eefcae525c20fd2ea953c4a8fb.slin48' (language 'en')
Background():
Playing 'custom/MainMenu.slin' (language 'en')
Another thought, since Asterisk is multicore and multithreaded but JS is single threaded, (even if we run the application on both cores npm run deploymulticore I see that only one JS app is getting the calls from Asterisk.) I guess that this is adding to our issue.