Difference between revisions of "Performance Suggestions M4"

From Kolmisoft Wiki
Jump to navigationJump to search
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
=M2 Performance Tuning=
=M4 Performance Tuning=


Many of the settings described here will improve system performance at the cost of usability.
Many of the settings described here will improve system performance at the cost of usability.
Line 5: Line 5:
==SSD==
==SSD==


Use SSD disks for Database! This will greatly improve performance.
Use SSD disks for the Database! This will greatly improve performance.


==FreeSwitch configuration settings==


===Internal FreeSwitch database===
==Core configuration settings==


Configure FreeSwitch to store the internal database in RAM.
Several M4 configuration settings may improve performance. These settings must be set in '''/etc/m2/system.conf'''. M4 Core restart is required when you change these settings.
 
Check if configuration file '''/usr/local/freeswitch/conf/autoload_configs/switch.conf.xml''' contains variable '''core-db-name'''. Set this variable to:
 
<param name="core-db-name" value="/dev/shm/core.db" />
 
If the variable is missing, add it. If the variable is commented out, uncomment it. Freeswitch restart is required.
 
===Disable FreeSwitch logs===
 
Disabling FreeSwitch logs will decrease the load on HDD/SSD.
 
In configuration file '''/usr/local/freeswitch/conf/autoload_configs/logfile.conf.xml''' comment out line:
 
<map name="all" value="console,debug,info,notice,warning,err,crit,alert"/>
 
Or you may remove only debug, info and notice messages. Note that the HTML comment format is used.
 
In configuration file '''/usr/local/freeswitch/conf/autoload_configs/switch.conf.xml''' set:
 
<param name="loglevel" value="0"/>
 
FreeSwitch restart is required.
 
==M2 Core configuration settings==
 
There are several M2 configuration settings that may improve performance. These settings must be set in '''/etc/m2/system.conf'''. M2 Core restart is required when you change these settings.


===cdr_batch_size = x===
===cdr_batch_size = x===


Here '''x''' is how many CDRs should be stored in a buffer before M2 Core inserts them to MySQL database. The default value is 30. Useful values are between 10 and 100.  
Here '''x''' is how many CDRs should be stored in a buffer before M4 Core inserts them into MySQL database. The default value is 30. Useful values are between 10 and 100.  


It is faster to insert CDRs in batches but the bigger the batch size the less frequently CDR will be inserted to the database.
It is faster to insert CDRs in batches. The bigger the batch size the less frequently CDR will be inserted into the database.


===cdr_flush_time = x===
===cdr_flush_time = x===
Line 56: Line 29:
'''show_error = 0'''<br>
'''show_error = 0'''<br>


These variables will disable M2 Core logging and thus decreases the load on HDD/SSD. If warnings and errors are important, you may leave show_warning = 1 and show_error = 1.
These variables will disable M4 Core logging and thus decrease the load on HDD/SSD. If warnings and errors are important, leave show_warning = 1 and show_error = 1.


===balance_check_period = x===
===balance_check_period = x===


Here '''x''' is how ofter to check the balance for active calls. The default value is 1 (check every second). You may set this value to higher (let’s say check every 5 seconds) but then there is a risk that calls may last 5 seconds longer than balance allows. This is not a problem if you have set a very high balance for your clients and you are not worried about balance going too low. In that case, you may set even higher value for balance check. Note that balance check is used only to prevent balance from dropping lower than the balance limit is set to. Call billing does not depend on this variable and will be accurate in all cases.
Here '''x''' is how often to check the balance for active calls. The default value is 1 (check every second). You may set this value to higher (let’s say check every 5 seconds) but then there is a risk that calls may last 5 seconds longer than balance allows. This is not a problem if you have set a very high balance for your clients and are not worried about the balance going too low. In that case, you may set an even higher value for the balance check. Note that a balance check is used only to prevent the balance from dropping lower than the balance limit is set. Call billing does not depend on this variable and will be accurate in all cases.


===active_calls_check_period = x===
===active_calls_check_period = x===
Line 68: Line 41:
===log_only_last_cdr = 1===
===log_only_last_cdr = 1===


M2 Core creates CDR for each call attempt through Terminators. If you enable log_only_last_cdr then only the last attempt will be stored to the database. This way CDR inserts will be less frequent and the database will be smaller.
M4 Core creates CDR for each call attempt through Terminators. If you enable log_only_last_cdr, only the last attempt will be stored in the database. This way CDR inserts will be less frequent and the database will be smaller.


===do_not_log_system_cdrs = 1===
===do_not_log_system_cdrs = 1===
Line 82: Line 55:
If you are not using advanced routing (routing by quality) you may disable this feature as it passively stores data required for advanced routing (even if you have not configured advanced routing in GUI).
If you are not using advanced routing (routing by quality) you may disable this feature as it passively stores data required for advanced routing (even if you have not configured advanced routing in GUI).


==M2 GUI configuration settings==
<br><br>
 
==M4 GUI configuration settings==


===Call limit/capacity===
===Call limit/capacity===


Enable limits if you really need them. If you don’t need concurrent call limits, set them to 0. If call limits are enabled, M2 Core has to count concurrent calls for User/Device and this takes system resources.
Enable limits if you really need them. If you don’t need concurrent call limits, set them to 0. If call limits are enabled, M4 Core has to count concurrent calls for User/Device and this takes system resources.


===Failover Routing Group===
===Failover Routing Group===


M2 Core has to retrieve all required information for Failover Routing Groups (dial peers, terminators, rates) before the call is even made. If you use Failover Routing Groups, try to make them as small as possible (few dial peers and few terminators).
M4 Core has to retrieve all required information for Failover Routing Groups (dial peers, terminators, rates) before the call is even made. If you use Failover Routing Groups, try to make them as small as possible (few dial peers and few terminators).


===Destination mask in Dial Peer settings===
===Destination mask in Dial Peer settings===
Line 98: Line 73:
===Archived calls===
===Archived calls===


Use archive calls feature to keep your database small. Queries run faster on smaller databases.
Use the archive calls feature to keep your database small. Queries run faster on smaller databases.


===Bypass Media in Connection Point settings===
===Bypass Media in Connection Point settings===
When set, the media (RTP) from the originating endpoint is sent directly to the destination endpoint and vice versa. The signaling (SIP) for both endpoints still goes through M2, but the media is point-to-point.
When set, the media (RTP) from the originating endpoint is sent directly to the destination endpoint and vice versa. The signaling (SIP) for both endpoints still goes through M4, but the media is point-to-point.
 
 
Enable this setting if you are sure that both Originator and Terminator uses the same codec. This will greatly improve FreeSwitch performance as switch no longer has to process media data.
Enable this setting if you are sure that both Originator and Terminator use the same codec. This will greatly improve RPTEngine performance as the switch no longer has to process media data.

Latest revision as of 18:04, 23 October 2024

M4 Performance Tuning

Many of the settings described here will improve system performance at the cost of usability.

SSD

Use SSD disks for the Database! This will greatly improve performance.


Core configuration settings

Several M4 configuration settings may improve performance. These settings must be set in /etc/m2/system.conf. M4 Core restart is required when you change these settings.

cdr_batch_size = x

Here x is how many CDRs should be stored in a buffer before M4 Core inserts them into MySQL database. The default value is 30. Useful values are between 10 and 100.

It is faster to insert CDRs in batches. The bigger the batch size the less frequently CDR will be inserted into the database.

cdr_flush_time = x

Here x is how often to flush CDR batch to MySQL database (in seconds). The default value is 5 seconds. Useful values are between 1 and 60.

logging

show_debug = 0
show_notice = 0
show_warning = 0
show_error = 0

These variables will disable M4 Core logging and thus decrease the load on HDD/SSD. If warnings and errors are important, leave show_warning = 1 and show_error = 1.

balance_check_period = x

Here x is how often to check the balance for active calls. The default value is 1 (check every second). You may set this value to higher (let’s say check every 5 seconds) but then there is a risk that calls may last 5 seconds longer than balance allows. This is not a problem if you have set a very high balance for your clients and are not worried about the balance going too low. In that case, you may set an even higher value for the balance check. Note that a balance check is used only to prevent the balance from dropping lower than the balance limit is set. Call billing does not depend on this variable and will be accurate in all cases.

active_calls_check_period = x

Here x is how often to refresh active call information. The default value is every 5 seconds. You may increase this value to decrease the load on the database.

log_only_last_cdr = 1

M4 Core creates CDR for each call attempt through Terminators. If you enable log_only_last_cdr, only the last attempt will be stored in the database. This way CDR inserts will be less frequent and the database will be smaller.

do_not_log_system_cdrs = 1

If this setting is enabled then FAILED calls with HGC >= 300 will not be stored to the database. This will slightly improve performance by having a smaller database and less frequent inserts to the database.

do_not_log_failed_cdrs = 1

If this setting is enabled then only answered calls will be stored in the database. This will slightly improve performance by having a smaller database and less frequent inserts to the database.

disable_advanced_routing = 1

If you are not using advanced routing (routing by quality) you may disable this feature as it passively stores data required for advanced routing (even if you have not configured advanced routing in GUI).



M4 GUI configuration settings

Call limit/capacity

Enable limits if you really need them. If you don’t need concurrent call limits, set them to 0. If call limits are enabled, M4 Core has to count concurrent calls for User/Device and this takes system resources.

Failover Routing Group

M4 Core has to retrieve all required information for Failover Routing Groups (dial peers, terminators, rates) before the call is even made. If you use Failover Routing Groups, try to make them as small as possible (few dial peers and few terminators).

Destination mask in Dial Peer settings

Destination mask Lithuania% is much faster than %Lithuania%. Try to avoid wildcard % in front of the name.

Archived calls

Use the archive calls feature to keep your database small. Queries run faster on smaller databases.

Bypass Media in Connection Point settings

When set, the media (RTP) from the originating endpoint is sent directly to the destination endpoint and vice versa. The signaling (SIP) for both endpoints still goes through M4, but the media is point-to-point.

Enable this setting if you are sure that both Originator and Terminator use the same codec. This will greatly improve RPTEngine performance as the switch no longer has to process media data.