ARI Question

Hey all,

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:

[[email protected] ~]# 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?

Thank you

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.

I would replace the external calls with do-nothing stubs that return immediately to separate .

Are you forcing Asterisk to transcode?

Hi Josh,

What debug level should I enable? Right now I have Debug level set at 3 and I see the following logs: (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.

We have the Trunk set to accept alaw & ulaw. It is playing the files using slin48.

Is the Background() situation also doing slin48? You generally don’t want to resample if possible, because that can be expensive.

Otherwise there’s nothing that stands out.

I guess that here is my answer…


Playing '/var/lib/asterisk/sounds/mt_schedules/57adb8eefcae525c20fd2ea953c4a8fb.slin48' (language 'en')


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. :frowning:

Depends on how much work the JS app is actually doing and what.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.