Making a FusionPBX with FreeSWITCH to hold a High CPS Index

FreeSWITCH it is an excellent soft switch, you can do all your imagination asks for. If you combining it with FusionPBX you can have a very nice experience managing your switch. However, the out-of-the-box configuration is not suitable for everyone. It happens I have a customer who uses the Freeswitch for call termination in a very particular way. They only serve a busy or calling tone (depending some conditions) to all the incoming calls.

The big issue here was the stress, the carrier they are using has a 3 seconds tolerance timeout and they need to serve as much calls as possible. The FusionPBX server was having an issue when receiving more than 200 cps, the carrier was reporting times out (more than 3 seconds to answer). In this article, I will try to put notes of what I did to increase the cps up to 450 (as 450 was the number my customer reported). Please note this VoIP switch are not intented for end-user use, some of the techniques won't apply to other kind of deployments.

Use my RPM's

Although this could be debatable. I have spent a lot of hours optimizing them. My RPM's have some ulimit optimization that will work not only with the classic systemv (/etc/init.d scripts) but with the new systemd (available since CentOS 7). If you want to try, you can read the RPM repository setup guide.

Create a good Memcached Topology

Memcached is awesome, you can store there any kind of information you want. The main purpose of Memcache in a FusionPBX server is trying to avoid database access as much as possible. Database access is well known to be slow (regardless what kind of database you use). Using a good topology will help you to improve this. FusionPBX has in the XML-Handler script file some Memcached values already, you can raise them as much as you want. The bigger you put those values, the less it will require accessing the database.

Another thing is you need to decide how are you going to play with the memcached. In this very specific case, my customer agreed to put one Memcached in each server and a dedicated Memcached server. Eventually, the local Memcached daemon will have the right information and as it is local, it will serve faster than the remote one.

But this is not enough.

Database Optimization

FusionPBX uses the database to store all kind of information. If you have a good Memcached deployment maybe you couldn't notice any database slowness. However, it is very important to try to reduce database delays as much as possible. FreeSWITCH will block a call until the database query (if any) is completed. I use MariaDB (a fork of MySQL).

I started by using the mysql-tuning tool. It is not perfect, but it allows you to give a pretty good idea what to do. In my case I did the following:

• increase the InnoDB buffer (default is 128 kB, not enough),
• increase the thread cache (1 per CPU),
• decrease the connections time-out (FreeSWITCH it is intelligent enough to reopen it if it is closed),
• increase maximun connections (default is 151, which it is almost enough for the major part of deployments), and
• increase the query cache.

If you are not using my RPMS for FusionPBX, you need to know that the vanilla installation does not add indexing to the database. This makes any database to be slow as a turtle or a snail! You may want to add indexes to your database.

But this is not enough.

Unload useless Modules

You just edit the modules.conf.xml file and take out all the modules you won't use. It will make the processing faster. If you are using FusionPBX, don't take out mod_lua and mod_memcached. Depending on your needs, you may or may not disable the mod_xml_cdr module.

Reduce the I/O

I/O is always a problem, FreeSWITCH will block a call until the I/O operation is finished. But some I/O operations are not always avoidable, so the first step is to make them as fast of possible. Fortunately, Linux has what we call a tmpfs file system. This kind of file system will keep the content in RAM as much as possible, and if the memory is required, it will use swap memory to temporally store until the RAM is freed. So, a smart step is to make the db directory this kind. Just type the following command:

echo tmpfs /var/lib/freeswitch/db tmpfs defaults 0 0 >> /etc/fstab

Remember to mount the file system. If you are not using my RPM's you will need to look for the correct location of your db directory.

Other think you must do is to tell FreeSWITCH to allow more sessions, not to keep track of sessions and do not use the database. All this is in your switch.conf.xml file, do the following:

• rise the value of the session-per-second to a value that suits your needs
• delete any parameter called core-db-dns or core-recovery-db-dsn

You are done. My customer told me he was able to rise 450 cps without a problem. You can do your tests by stressing your FreeSWITCH server by your own.

Good Luck!