VitalPBX-Asterisk Stress Test

In this tutorial, we will show you how to perform a test to know the capacity of simultaneous calls in VitalPBX and Asterisk PBX depending on the hardware.

For a long time many people have asked us the following:
“What is the concurrent call capacity of VitalPBX or Asterisk?… What is the bandwidth consumption for calls in VitalPBX or Asterisk?”

We took on the task of conducting an investigation of how to perform a test of concurrent calls and we realized that the information was very poor and did not meet our expectations. So we decided to make a script to test the capacity of concurrent calls in VitalPBX depending on the hardware it has been installed on and bandwidth consumption..

---

Prerequisites

To do this test it is necessary to have two VitalPBX servers installed, the server on which we will perform the tests and the remote server to which we will connect. It should be noted, that it is necessary that the remote VitalPBX server should have more capacity than the local one. Because if it had less capacity, it will not stress test the maximum capacity of the local server.

Recommendations

• Wait at least five minute between each test, since the load parameter is an indication of the last minute load. Use the uptime command to ensure that load is below 0.10.
• It is recommended to do this test on a completely clean server, without previous configurations. VitalPBX recently installed.

Script VitalPBX V3 and V4

Next, copy and run the following script on the server you wish to stress test

[root@vitalpbx1 ~]#  cd /
[root@vitalpbx1 ~]#  wget https://raw.githubusercontent.com/VitalPBX/VitalPBX-Stress-Test/master/stress-test.sh
[root@vitalpbx1 ~]#  chmod +x stress-test.sh
[root@vitalpbx1 ~]#  ./stress-test.sh

Set up the following information (In your case the values can change):

IP Local....................................... >  192.168.30.10	
IP Remote...................................... >  192.168.30.20
SSH Remote Port (Default is 22)................ >  22
Network Interface name (ej: eth0).............. >  eth0
Protocol (1.-SIP, 2.-IAX, 3.-PJSIP)............ >  1
Codec (1.-None, 2.-G79, 3.- GSM)............... >  1
Recording Calls (yes,no)....................... >  no
Max CPU Load (Recommended 75%)................. >  75
Calls Step (Recommended 5-100)................. >  50
Seconds between each step (Recommended 5-30)... >  5

Are you sure to continue with these settings? (yes,no) > yes

Are you sure you want to continue connecting (yes/no)? yes

[email protected]'s password: The root password from Remote Server

Note:
The test cannot last more than 10 minutes due to the duration of the audio. If you want a longer duration, change the audio or add more time to the "demo-instruct" audio on this line on the stress-test.sh script:
asterisk -rx "channel originate Local / 200 @ call-test-ext application Playback demo-instruct&demo-instruct......

Test results

These are the descriptions of each column in the result:

• Step, Number of tests that are done every N seconds.
• Calls, Number of calls generated by the test.
• Asterisk Calls, number of calls that asterisk currently has in progress.
• CPU Load, percentage of CPU used, if the CPU has more than one Core, this percentage is already taken into account.
• Load, cpu load average in the last minute. If this number is greater than the number of cores that the cpu has, it means that processes are remaining in the queue, which seriously affects calls.
• Memory, percentage of memory being used.
• BW TX kb/s, upload bandwidth in kb/s on the call.
• BW RX kb/s, download bandwidth in kb/s in the call.

Hardware Info

Motherboard----> Raspberry Pi 4 Model B
CPU Model------> Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz
CPU Cores------> 4
MEMORY RAM-----> 4 GB

Hardware Info

Motherboard----> YANYU STX-R19F
CPU Model------> Intel(R) Celeron(R) CPU J1900 @ 1.99GHz
CPU Cores------> 4
MEMORY RAM-----> 4 GB

Hardware Info

Motherboard----> YANYU STX-N92_VER:1.0
CPU Model------> Intel(R) Core(TM) i5-4210Y CPU @ 1.50GHz
CPU Cores------> 4
MEMORY RAM-----> 4 GB

Hardware Info

Motherboard----> Virtual
CPU Model------> 4 threads, 4GB RAM, M1 Max - ARM CPU
CPU Cores------> 4
MEMORY RAM-----> 4 GB

Hardware Info

Provider----> Digital Ocean
CPU Model------> Xeon E-2286G 4 GHz 
CPU Cores------> 6 Cores -12 threads 
MEMORY RAM-----> 32 GB
Disk-----------> 2x960 GB SSD

Conclusions

In the tests done to the Raspberry PI 3+ without using any type of codec and without recording of calls a total of up to 80 concurrent calls was achieved using 94% of CPU Processing and only 27% of memory, which we conclude Asterisk requires mostly processor resources when making a call. When we add call recording, the reduction in call capacity is 25%, that is 80 to 60 simultaneous calls. The most marked difference is when we use codec g729, there is a decrease in capacity of 50% and it increases to 60% less when we add call recording with the codec g729. In conclusion, the use of codecs affects the performance of our PBX by quite a lot, however, the benefit we have is the reduction of consumption bandwidth from 85K to 30k per call, approximately. We believe it is advisable not to use codecs since in this day and age, since the bandwidth that the ISPs offer us are much better than past decades, where compression was really needed.

We could see the same behavior when the tests were performed on an Intel Celeron J1900 processor and a 4th generation Intel Core i5 with 4GB of RAM.

Another conclusion we cam to with these tests, is that the memory is not very important with respect to concurrent calls in Asterisk, however, in some cases it is necessary since not only the Asterisk application is executed on a server with VitalPBX. We recommend not to commit the error of believing that increasing the memory will increase the processing capacity of concurrent calls from our server.

Recommendations

1.-Always size the server with a test of 50% (maximum) of occupation, that is to say, when performing the test take as the maximum when the occupation of the CPU reaches 50%. This is because you have to take into account that we may have other applications running on the same server at any given time.
2.- Do not make the mistake of over-sizing the server. in many cases, with 4GB of RAM is more than enough.
3.- Use solid state drives, since this increases the speed of execution for any process.
4.- Never do this test on a server that is in production. Perform this test before deploying any server with VitalPBX.
5.- All of your comments are welcome.