Improving MiRTA PBX speed - Revision history

Admin: /* Generating only needed Manager Events */

2020-09-25T17:36:49Z

Generating only needed Manager Events

← Older revision		Revision as of 17:36, 25 September 2020
Line 81:		Line 81:
	eventfilter=Event: UserEvent		eventfilter=Event: UserEvent
	eventfilter=Event: QueueParams		eventfilter=Event: QueueParams
	eventfilter=Event: ~~QueueMemberPaused~~		eventfilter=Event: QueueMemberPause
	eventfilter=Event: ParkedCall		eventfilter=Event: ParkedCall
	eventfilter=Event: UnParkedCall		eventfilter=Event: UnParkedCall

2020-07-25T07:32:51Z

← Older revision		Revision as of 07:32, 25 July 2020
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

2018-04-10T19:41:36Z

Generating only needed Manager Events

← Older revision		Revision as of 19:41, 10 April 2018
Line 61:		Line 61:

	== Generating only needed Manager Events ==		== 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:

			<pre>[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</pre>

2018-04-10T19:20:00Z

← Older revision		Revision as of 19:20, 10 April 2018
Line 59:		Line 59:

	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		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 ==

2018-04-07T06:27:52Z

← Older revision		Revision as of 06:27, 7 April 2018
Line 56:		Line 56:
	rm /var/lib/asterisk/astdb.sqlite3		rm /var/lib/asterisk/astdb.sqlite3
	service asterisk start		service asterisk start
	<pre>		</pre>

	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		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

2018-04-02T10:53:45Z

← Older revision		Revision as of 10:53, 2 April 2018
Line 35:		Line 35:

	<pre>		<pre>
	none /var/lib/asterisk/astdb tmpfs noatime,nodev,nosuid,noexec,mode=~~0750~~ 0 0		none /var/lib/asterisk/astdb tmpfs noatime,nodev,nosuid,noexec,mode=0755 0 0
	</pre>		</pre>

2018-04-02T10:49:49Z

← Older revision		Revision as of 10:49, 2 April 2018
Line 1:		Line 1:
	~~ 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.		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.

2018-04-02T10:49:38Z

Installing HHVM

← Older revision		Revision as of 10:49, 2 April 2018
Line 15:		Line 15:
	On CentOS 6.x		On CentOS 6.x
	<pre>		<pre>
	~~rpm -Uvh~~ http://~~dheche~~.~~fedorapeople~~.~~org~~/~~hhvm~~/el6/~~RPMS/x86_64/hhvm-release-6-1.noarch~~.~~rpm~~		cd /etc/yum.repos.d
			wget http://www.hop5.in/yum/el6/hop5.repo
	yum -y install hhvm		yum -y install hhvm
	</pre>		</pre>

2018-04-01T15:54:54Z

← Older revision		Revision as of 15:54, 1 April 2018
Line 1:		Line 1:
	~~======~~ DO NOT PROCEED IN THESE SETTINGS, THERE ARE PROBLEMS UNDER INVESTIGATIONS ~~======~~		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.		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.

2018-04-01T15:54:34Z

← Older revision		Revision as of 15:54, 1 April 2018
Line 1:		Line 1:
	~~*************~~ DO NOT PROCEED IN THESE SETTINGS, THERE ARE PROBLEMS UNDER INVESTIGATIONS ~~***************~~		====== 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.		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.