8 tips for improved SugarCRM performance

Estimated reading time: 17 min

Speed up SugarCRM performance

Ever wondered why at some point your SugarCRM instances just slow down? Looking for a go-to place for speed-oriented best practices? Check out these 8 tips and improve your on-premise SugarCRM performance. Straightforward explanations and example configurations included for your convenience so read on and let your instances work blazing fast with the following solutions.

SugarCRM performance over time

Almost every enterprise computer system is expected to grow over time as consequence of its normal everyday use. SugarCRM is no different. As time goes by you will have more files stored on disk and more records in the database. Usually, the number of users grows as well. In result of the larger footprint and higher concurrency you will need more system resources. This is particularly noticeable in on-premise deployments where the write-to-read ratio is high (eg. busy call centers).

Sometimes it comes to a point where the currently available resources are insufficient and the application performance becomes impaired. Significantly scaling the infrastructure is one way to circumvent the issue. However, sometimes it is not a viable option or you have limited hardware upgrade possibilities. Luckily there are some tips and tricks you can use to speed up and squeeze the most out of SugarCRM.

1. SugarCRM release and PHP version

„Upgrade to a newer version” might sound like a cheesy first piece of advice. In reality that’s the first thing you should do, especially if you are still running SugarCRM 7.x. In the last few years, folks at SugarCRM have done lots of hard work to effectively improve the system. Between versions 7 and 9 there are quite a few significant performance upgrades. At the same time, many bugfixes and security enhancements were introduced. Going with the latest version can bring as much as faster list views, filters and subpanels plus greatly improved API performance.

Upgrading to version 9 should also be discussed in context of the underlying PHP version. If you are running PHP 7.1 you could switch to 7.3 which is 22% faster (phpbench 0.8.1). Version 7.1 is already in the “security fixes onlylife stage and 1st Dec 2019 marks the EOL (end of life). After this date, there will be no more updates of any kind. If you don’t upgrade, sooner or later your infrastructure might become vulnerable. If by any chance you are still running 5.6, upgrade immediately as it’s not supported since 1st Jan 2019. Make sure you review all custom code against compatibility with PHP 7 before switching from 5.6. Afterwards monitor PHP error logs to catch any additional issues that might’ve slipped through the initial review.

SugarCRM releaseSupported PHP versions
SugarCRM 9.07.1, 7.3
SugarCRM 8.07.1
SugarCRM 7.95.6, 7.1

2. PHP-FPM

Thinking about PHP there’s yet another aspect where significant performance gains can be achieved. If you are using Apache with mod_php it’s definitely worth switching to PHP-FPM. Some studies show over 300% improvement in average response time. Once you set it up, you will be amazed by how noticeably faster things run. What’s even better PHP-FPM allows scaling via flexible config so you can get the best bang for your infrastructure buck.

Make sure you monitor the average memory footprint of a single PHP worker process. Always do it if you plan on upgrading the configuration and also as part of routine maintenance. Armed with that knowledge you can precisely adjust the max_children parameter to maximize utilization of the available memory.

3. General settings

Some of the following advice might seem obvious, but let’s reiterate on the ground rules of SugarCRM performance-oriented configuration. In the administrative settings, keep the number of listview and subpanel items per page at bay. The default value of 20 for listviews is a good starting point. If your use case requires showing more than that, try not to exceed the advised maximum of 100. Remember that increasing the value above the defaults will impact performance. For subpanel items, the default is 10 and it’s already the advised maximal value.

Moving on, make sure you enable the scheduled job for periodical cleansing of soft-deleted records. Look for the Prune Database on the 1st of Month job and set it to Active. Oh and last but not least… Never leave developer mode or tracker performance and tracker queries enabled in a production environment. The same goes for setting the log level to anything more verbose than fatal. Unless ofcourse you are specifically troubleshooting some issues and need more detailed logs.

4. Core configuration

There are a few parameters in the config that you can switch to gain some speedups. Depending on the version of SugarCRM you are using, they can be effective to a varied degree. The newer the version, the more settings affect only modules in the BWC mode. Still, its worth to fine-tune them via the config_override.php file to gain some performance improvements.

$sugar_config['verify_client_ip'] = false;     
 // Prevents Sugar from checking on every request if the user’s IP has changed.

$sugar_config['disable_count_query'] = true; 
 // Hides the total record counts on list views and subpanels thus eliminating the need for expensive count queries

$sugar_config['save_query'] = 'populate_only';
 // Prevents Sugar from remembering the last searched results on list views ie. the user will have to manually search every time

$sugar_config['hide_subpanels'] = true;
 // By default keeps all the subpanels collapsed only to load data when the user explicitly asks for it

$sugar_config['hide_subpanels_on_login'] = true;
 // When the user explicitly expands a subpanel it will be automatically collapsed on next login

5. Zend OpCache

The Zend OpCode cache comes bundled and readily available in most modern PHP distributions. When enabled and properly configured, this extension provides impressive SugarCRM performance improvements (and all PHP apps in general). It’s not uncommon to see instant 300-500% speed up once it’s turned on. Provided you ensure enough memory, enabling the opcache is seamless. Therefore turning it on in your production environment is strongly recommended.

However, be advised that depending on your SugarCRM use case, enabling a misconfigured opcache might have unexpected results. If you use Studio to manage and customize your instance make sure that opcache revalidation is properly configured. The opcode cache should be emptied based on file modified timestamps rather than the usual revalidate frequency. Example config for a Studio-enabled deployment can be as follows:

opcache.revalidate_freq = 0
# Disable time based cache revalidation

opcache.validate_timestamps = 1
# Enable modified timestamp based revalidation

opcache.memory_consumption = 512
# Memory allowance, best to keep it high

opcache.max_accelerated_files = 100000
# Max number of files that will be cached

opcache.interned_strings_buffer = 32
# Especially useful with PHP-FPM, shared variable values pool

opcache.fast_shutdown = 1
# Quick object shutdown

6. External cache with Redis

SugarCRM offers a flexible inbuilt cache interface for storing application data. Many different cache backends are supported and the whole feature is called external cache in SugarCRM’s nomenclature. While doing custom development it’s worth utilizing the external cache. Use it for often-repeatable calculations’ results, data that doesn’t change much or outcomes of costly computations. Once cached, the data will be retrieved faster and this will speed up the overall user experience. Moreover, it will reduce the server load too.

SugarCRM itself uses the mechanism to cache part of its own application data. Therefore choosing the right cache backend can considerably improve general instance performance. Redis is a popular choice thanks to its impressive robustness, speed and scalability. Often it’s being used for handling PHP session data. If you already have a Redis instance up and running in your infrastructure, you can easily use it as the external cache backend.

 $sugar_config['external_cache_disabled'] = false;  
 // Enables external caching


$sugar_config['external_cache_disabled_redis'] = false; 
// Enables Redis


$sugar_config['external_cache']['redis']['host'] = 127.0.0.1; 
// IP of your Redis instance


$sugar_config['external_cache']['redis']['port'] = 6380; 
// Only required if port different than the default 6379

7. Slave database

SugarCRM Enterprise and Ultimate offer a great feature that allows redirecting costly read-only operations to a slave database. This can be enabled for list views, dashlets and subpanels as well as reports. Reports and list views often put significant load on the database. Therefore separating out such queries from the main database instance often helps in alleviating some speed issues and improving general SugarCRM performance. Larger deployments where the Reports module is extensively used will benefit most from this solution.

Bear in mind that you need to set up the slave database and replication mechanisms on your own. SugarCRM will not sync data from the live database by itself. There are 2 configuration key groups available to offload the desired pieces of functionality to the slave database. Reports and Listviews, whereas the latter beside listviews also covers subpanels and dashlets.

In result an example config can look like the following:

$sugar_config['db']['reports']['db_host_name'] = 'sugar_slave'; // The host name of the server running the slave database

$sugar_config['db']['reports']['db_user_name'] = 'slave_user';
// The user name to connect to the slave database

$sugar_config['db']['reports']['db_password'] = 'slave_password';
// The password to connect to the slave database

$sugar_config['db']['reports']['db_name'] = 'sugarcrm_slave';
// The name of the slave database

$sugar_config['db']['reports']['db_type'] = 'mysql';
// The type of database running the slave (DB2, mysql, mssql, oracle)

$sugar_config['db']['listviews']['db_host_name'] = 'sugar_slave';
$sugar_config['db']['listviews']['db_user_name'] = 'slave_user';
$sugar_config['db']['listviews']['db_password'] = 'slave_password';
$sugar_config['db']['listviews']['db_name'] = 'sugarcrm_slave';
$sugar_config['db']['listviews']['db_type'] = 'mysql';

8. Team denormalization

Last but not least there’s one more trick you could use to improve the performance of your SugarCRM instance. The caveat here is that it’s not for everyone. You should use it only in specific circumstances. It’s called team denormalization and its main focus is to simplify and thus improve the performance of internal runtime SQL queries related to record visibility – executed to show records only to the current user. As the name states, the merit of this feature is to denormalize the information about user/team-set assignment. Thanks to that SugarCRM can quickly determine if the given user is tied to a specific Team Set.

It was mentioned before that this performance improvement is not always a viable option. This enhancement will be most beneficial for modules that have more than a few hundred thousand records. The baseline criterion to consider is having more than 100 000 unique Team Set combinations. In general team denormalization is highly recommended for SugarCRM instances that use the standard team security for data visibility purposes and meet the aforementioned baseline criteria for Team Set quantity. It is not recommended to enable the feature if you are using custom visibility rules.

To enable team denormalization, first set the relevant config in config_override.php file:

$sugar_config['perfProfile']['TeamSecurity']['default']['use_denorm'] = true; 
// Enables team denormalization

$sugar_config['perfProfile']['TeamSecurity']['inline_update'] = true; 
// Allows the denorm tables to be updated in real time 

Next, run the command in the console to ensure that the initial denormalization is performed:

 ./bin/sugarcrm team-security:rebuild 

More ways to speed up

If your on-premise deployment starts to slow down, apply the aforementioned tips to regain some SugarCRM performance. If your use-case is integration heavy you can offload part of the burden to a separate dedicated instance. Likewise, do it if you have a lot of scheduled jobs running via CRON. The separation will limit the workload impact on the performance of regular users’ everyday tasks. This brings its own set of challenges and complexity but it’s worth having options, right? Diving deeper into the subject of multi-instance deployments is outside the scope of this article. However as mentioned before, good to know there are still some ways to speed up SugarCRM.

Obviously, sometimes a hardware upgrade is just the only solution left if you really hit the roof with resource consumption. Thinking about RAM and CPU is an obvious choice but there’s more to it than meets the eye. The single biggest benefit you can get from an infrastructure change is switching from regular HDD to SSD drives. Most often this brings unbelievable performance gains. Yet again, infrastructure changes as such are a subject for another article so stay tuned.

If you found this post helpful, have follow-up ideas or just want to chat – let me know. I’m always happy to answer questions and help out!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.