Improving MiRTA PBX speed: Difference between revisions
No edit summary |
|||
Line 86: | Line 86: | ||
eventfilter=Event: ParkedCallTimeOut | eventfilter=Event: ParkedCallTimeOut | ||
eventfilter=Event: ParkedCallGiveUP</pre> | eventfilter=Event: ParkedCallGiveUP</pre> | ||
== 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 |
Revision as of 07:32, 25 July 2020
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: QueueMemberPaused 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