Improving MiRTA PBX speed

• • DO NOT PROCEED IN THESE SETTINGS, THERE ARE PROBLEMS UNDER INVESTIGATIONS **

When comparing MiRTA PBX with a vanilla Asterisk performing the same task, you'll notice MiRTA PBX performance are worst. This is due to the fact when tailoring a vanilla Asterisk for a specific task, it has to perform just that task, while when using MiRTA PBX, it will still check for any feature, option or command you may specify. Obviously, this takes time.

However, MiRTA PBX has an advantage over a vanilla Asterisk. MiRTA PBX performances scale linearly (or almost linearly) with the number of servers installed, so if your MiRTA PBX is starting suffering for high load, you just need to add a node to your cluster (an asterisk node or a MySQL node or a web frontend node) and evenly distribute the load.

It is, however, possible you want to squeeze all the juice from your current MiRTA PBX hardware before adding a new node. So here I am listing the possible options you can adopt for improving MiRTA PBX speed without giving up any of his features.

Database partition

Accessing the Status/Call History can put an high stress on the MySQL. You can mitigate using the "Simple" view or by partitioning the MySQL cdr table

Installing HHVM

HHVM is a JIT compiler for PHP and it should improve execution time for the daemons run in PHP (devstatesender.php, devstatereceiver.php and others). You may need to restart the .sh process to enable it

On CentOS 6.x

rpm -Uvh http://dheche.fedorapeople.org/hhvm/el6/RPMS/x86_64/hhvm-release-6-1.noarch.rpm
yum -y install hhvm

On CentOS 7.x

rpm -Uvh http://mirrors.linuxeye.com/hhvm-repo/7/x86_64/hhvm-3.15.3-1.el7.centos.x86_64.rpm

Moving astdb to ramdisk

Asterisk maintains its current state in a SQLite3 database named astdb and located in /var/lib/asterisk/astdb.sqlite3. Due to several reasons, this database can get big and slow. Due to the nature of the information stored, it is safe to delete this database when restarting asterisk or move it on a temporary storage area being discarded at reboot. Being a database, Asterisk flushes his state to disk for each operation and depending on your hardware subsystem, this may take time. Moving to a tmpfs, just reduce this time improving Asterisk extension registration time.

Create a directory to store the astdb

mkdir /var/lib/asterisk/astdb

Add instructions to create a ramdisk and mount on the above created directory. Edit /etc/fstab and add the following row

none /var/lib/asterisk/astdb tmpfs noatime,nodev,nosuid,noexec,mode=0750 0 0

Mount the newly created tmpfs with

mount -a

Edit /etc/asterisk/asterisk.conf and change the astdbdir to

astdbdir => /var/lib/asterisk/astdb

Stop asterisk, remove the old astdb.sqlite3 database and restart asterisk. Perform this out of work hours.

service asterisk stop
rm /var/lib/asterisk/astdb.sqlite3
service asterisk start

Restart devstate sender and receiver. This is important because devstatesender.php and devstatereceiver.php maintain a cache of the asterisk extension state and this cache will no more in sync after astdb deletion