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.
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.
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 Network Interface name (ej: eth0).............. > eth0 Protocol (1.-SIP, 2.-IAX)...................... > 1 Codec (1.-None, 2.-G79, 3.- GSM)............... > 1 Recording Calls (yes,no)....................... > no Max CPU Load (Recommended 90%)................. > 90 Calls Step (Recommended 5-20).................. > 10 Seconds between each step (Recommended 5-30)... > 10
Are you sure to continue with these settings? (yes,no) > yes
Are you sure you want to continue connecting (yes/no)? yes
firstname.lastname@example.org’s password: The root password from Remote Server
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......
Hardware Info Motherboard----> Raspberry Pi 3 Model B Plus Rev 1.3 CPU Model------> ARMv7 Processor rev 4 (v7l) CPU Cores------> 4 MEMORY RAM-----> 1 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
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.
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.
For more information on the stress-test go to: