Performance Tuning: Sugar - 1CRM (info@hand) - intelecrm - SuiteCRM

Article ID: 245

Last updated: 15 Nov, 2016

Background

On occasion, a deployment of the Riva On-Premise server can cause so many Apache instances to be created on the Sugar host server that it utilizes all of the available memory. This results in an unusable Sugar server that needs a reboot to free the memory pool.

The information in this article can be applied to on-premises and hosted installations for:

Sugar (all editions - on-premise and hosted)
1CRM (on-premises; formerly known as info@hand)
intelecrm (on-premises)
1CRM Cloud
SuiteCRM (on-premises)

Performance Tuning

Working with several Sugar hosting providers, we have compiled a number of performance tuning tips that help to alleviate the memory consumption issue:

Tip #1: Set a reasonable value for Riva sync policy execution threads.
Tip #2: Disable NUSOAP debugging.
Tip #3: Do not leave log4net logging on DEBUG level.
Tip #4: NEVER leave "Developer Mode" enabled.
Tip #5: Override UI performance options for SOAP requests.
Tip #6: Implement a non-threaded, pre-forking Web server.

Tip #1: Set a reasonable value for Riva sync policy execution threads

In the Riva CRM Policy, in the Connections tab, you can set the execution threads value to define the number of user accounts that Riva CRM agent service will synchronize concurrently. The higher this value is set, the more system resource usage (memory consumption, CPU utilization, and disk I/O) increases.

The recommended value is between 1 to 3 for hosted Sugar services, and between 3 to 5 for on-premises Sugar servers.

Tip #2: Disable NUSOAP debugging

The simplest of changes to improve performance is to disable SOAP debugging. Oddly enough, PHP debug logging is enabled by default and does not actually debug anywhere but causes a HUGE amount of memory allocation and increases processing time. On Windows systems, the performance difference is significant: over 100X; while on Linux, there is a 10X performance increase.

To check, edit the /include/nusoap/nusoap.php file and set the debug level to 0, like this:

$GLOBALS['_transient']['static']['nusoap_base']->globalDebugLevel = 0;

One step even further is to remove all lines that start with:

$this->debug(

or

$this->appendDebug(

Tip #3: Do not leave log4net logging on DEBUG level

Check the log4net.properties file and the Sugar administration panel.

Tip #4: NEVER leave "Developer Mode" enabled

When "Developer Mode" is enabled, all PHP file caching is disabled, which causes every page load or execution to create an excessive +10MB/s of disk IO. Always keep Developer Mode disabled in production deployments.

Tip #5: Override UI performance options for SOAP requests

Because there is no end-user interaction, features that are implemented to improve the user experience can be disabled. Some features cause a small performance loss when used by single users, but when used by a service can cause a much higher performance loss.

Append the following to the config_override.php file prior to the closing PHP tag.


$file = $_SERVER["SCRIPT_NAME"];
$break = explode('/', $file);
$pfile = $break[count($break) - 1]; 
if(strtolower($pfile) == "soap.php")
{
    $sugar_config['log_level'] = 'fatal';  // can enable debug for only SOAP  requests.
    $sugar_config['log_memory_usage'] = false;
    $sugar_config['disable_count_query'] = true;   // major performance fix
    $sugar_config['verify_client_ip'] = false;
    $sugar_config['disable_vcr'] = true; // performance fix
}

Tip #6: Implement a non-threaded, pre-forking Web server

For detailed instructions on Sugar deployments that use the Apache web server, see Apache MPM prefork. See also this Omni discussion on performance tuning on Apache.