Unlike our other articles, this one is going to be a bit more technical. Our development team performed some tests to evaluate the performance of uContact achieving incredible results.
This test allowed us to verify what can be achieved with the uContact platform with similar production environments regarding the most important items like:
- Generating almost 270 calls per second, being all recorded, and generated through a SIP provider. We can go further if more than one dialer is on.
- Having dialers that can handle up to 5,500 simultaneous calls without performance issues, this is great for VoiceBroadcast campaigns that have to reach a big number of customers in a small timeframe.
- Having a controlled resources usage during the test without having uncontrolled load or CPU peaks (within the test limits)
- We are already working on a new Architecture that will push these limits even forward.
In order to test how far our system can go on demanding call centers, we created a series of test scenarios, configured with production settings for our VoiceBroadCast dialer including:
- List loading and balancing.
- Inter carrier operation through sip carriers. (ulaw codec without transcoding)
- Recording of all calls (gsm)
- Several Variables within call Origination.
- 4 minute calls
The main goals of the test where:
- Generate the max amount of calls without compromising audio quality.
- Measurement of system performance, in order to have the best performance without compromising stability of the system (login in, audio, call loss, packet loss, event loss).
- Have performance benchmark tables to compare performance based on hardware used.
Everything was running on Google Cloud Platform, mainly because it is our actual platform for cloud clients, and also because it gives us the possibility to grow our infrastructure depending on the customer needs.
Based on our experience, we generated four different instances in order to measure the performance. All the scenarios where created with two servers (one for telephony and one for application and database). The tests were running with the following software configuration:
- Database: MySQL 5.7.21
- OS: Ubuntu Server 16_04 LTS
- Kernel: 4.13.0
- Asterisk: 13.19.2
- uContact: 6.132
- Codec: ulaw (without transcoding)
- Scenario 1: 2 servers each one 4gb ram, 4 cores, SSD drive 10gb interface.
- Scenario 2: 2 servers each one 8gb ram, 8 cores, SSD drive 10gb interface.
- Scenario 3: 2 servers each one 32gb ram, 32 cores, SSD drive 10gb interface.
- Scenario 4: 2 servers each one 64gb ram, 64 cores, SSD drive 10gb interface.
The tests were performed measuring specific performance indicators, such as:
- Calls per second.
- Maximum calls per dialer.
- Maximum load without compromise system stability.
- Minimum available processor during peak activity.
- Maximum bandwidth.
- Maximum I/O response time.
All the tests where measured with system performance indicators and with voice quality, having real calls with music on hold on the carrier end in order to determine if audio suffered quality issues of any kind (packet loss, jitter, etc.)
All the metrics were gathered with Grafana and influxDB. This tool gave us the possibility to track all the information almost in real time from various aspects, all synchronized on the same timeline.
Calls per second.
The test was intended to measure how many calls per second could be made depending on the hardware configuration.
Based on the information generated, we could determine that the best performance was achieved with the configuration of the scenario 3, as it had a decent amount of simultaneous calls generated by the same dialer.
Maximum dialer calls.
The test was intended to measure the maximum amount of calls a dialer can handle at the same time, without compromising quality and stability of the system.
Here we can conclude that the hardware increase let the dialer generate a larger amount of simultaneous calls without compromising the system at any point.
In this case, we collected information from the operating system to follow the behavior of the overall system and detect bottle necks of any kind.
In any of the scenarios we let the load be higher than the 80% of the total cores with a view to preserve stability, also CPU utilization based on idle CPU on the pack processing stage.
Other items were taken into consideration because there are bottle necks both in hardware and networking infrastructure, so we have measured i/o time and maximum bandwidth utilization.
We´ve noticed that when most calls are made regarding on the hardware, the load queue was increasing exponentially being the scenario 2 the most stable of all.
The use of processor in all the tests was very similar without having peaks or instable processor usage, noticing a smooth increase on the usage up to a stabilization stage when max dialing.
In this measurement, we didn’t notice any different behavior being related directly to the amount of calls generated. In none of the scenarios we noticed data loss between server and carrier, generating a constant data flow.
In contrast with the increase of resources of each instance for scenarios, we didn’t change the storage throughput and maximum requests, in order to see the real performance increase on the same hardware (in this case SSD persistent storage).
The maximum i/o response time was during the peak recording storage in the end of scenario 4 testing, where most calls were generated. In the previous tests, the i/o response times where constant. As all the calls duration was 4 minutes we have many calls hanging up at the same time.
uContact is able to generate almost 270 calls per second, have dialers that can handle up to 5,500 simultaneous calls without performance issues and much more. It is your turn to check it out for yourself. What are you waiting for? Request a live demo now.