Improving MiRTA PBX speed

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

cd /etc/yum.repos.d
wget http://www.hop5.in/yum/el6/hop5.repo
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=0755 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

Generating only needed Manager Events

Asterisk generates lots of manager events that are used by devstatesender.php and devstatereceiver.php to handle the status of the extensions. They are also used by the realtime portal to show the call flow and extension status. With the increase of the number of event types generated by recent Asterisk versions, the load applied to Asterisk to generate all these events and the load applied to devstate application to handle them can be avoided by specifying only the events really needed. This list of events can change over the time, when new features will be added. A special note will be posted in the new version details.

In manager.conf needs to be modified to include the following info:

[manager]
secret=jkfu57fh3d7nms2
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.255
permit=.../255.255.255.255
permit=.../255.255.255.255
...
read = all,system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan
write = system,call,agent,user,config,command,reporting,originate
eventfilter=Event: ContactStatus
eventfilter=Event: PeerStatus
eventfilter=Event: Newstate
eventfilter=Event: Hangup
eventfilter=Event: UserEvent
eventfilter=Event: QueueParams
eventfilter=Event: QueueMemberPause
eventfilter=Event: ParkedCall
eventfilter=Event: UnParkedCall
eventfilter=Event: ParkedCallTimeOut
eventfilter=Event: ParkedCallGiveUP

Restrict Queues to only the server where they are used

In Asterisk Realtime, queues are stored in the queue table. Any server in the cluster is able to see them and hold their configuration in memory. This seems to slow down asterisk when the number of queues is really high. It is possible to restrict access to only the queue actually used by each server using a special table in extconfig.conf, like it happens for the sipregs table:

 sipregs => odbc,asterisk1,sipregs_srv02,1
 sipregs => odbc,asterisk2,sipregs_srv02,2
 ...
 queues => odbc,asterisk1,queue_srv02,1
 queues => odbc,asterisk2,queue_srv02,2

Once the configuration has been done, you need to reload the extconfig module