SugarCRM Performance Tuning While Working with Large Amounts of Data

SugarCRM Performance Tuning While Working with Large Amounts of DataAuthor: Katerina Burlaka, CRM Consultant

SugarCRM has proved the efficiency of solving the customers’ actual issues. SugarCRM is a system, used by tens of thousands of companies of different size across a broad range of industries all over the world.

How good and precise could be CRM system in meeting customers’ business requirements? How fast does SugarCRM system operate? How quick and prompt could be the work of the users inside the system?

It goes without saying that while working with relatively small amount of data, SugarCRM performance will be at an appropriate level. But sometimes there is a necessity for CRM system to work with large and even huge amount of data. In this case, unfortunately, the performance of out-of-the-box system leaves a lot to be desired. It especially concerns the cases of SugarCRM integration with systems that work with relatively large volume of data, for example, ERP systems or electronic trading platforms. Having solid experience in SugarCRM integration with various systems we’ve come to a conclusion that if to exploit the system in “extreme” conditions – then you may encounter some system performance issues.

As an example of the negative impact of large amount of data onto the work of the user inside CRM system let’s consider the operation of saving the call record. By saving the results of the call, the system performs the appropriate actions, including, for instance, updates to the current user’s calendar based on the made call. The standard implementation of this function requires the loading of hundreds of related objects and, consequently, thousands of queries to database. That leads to SugarCRM database overloading and highly affects CRM system performance. As a result the standard task of call saving is performed for a very long time, especially if the current user has got a lot of scheduled activities in his calendar.

Unfortunately, this is not the only non-optimal solution, made by SugarCRM developers that can become the cause of performance issue while working with large volumes of data.

How could we handle the issues of SugarCRM performance while working with large amounts of data?

1. Lazy loading

Out-of-the-box SugarCRM engine is quite eager when it comes to loading objects. It actually loads a bunch of objects that are related to needed one and sometimes it loads the objects related to the objects related to the objects… The way SugarCRM engine deals with objects is quite simple and convenient from development perspective, and it is nice when all potentially needed objects are at hand from business perspective. But from the performance perspective it could be a nightmare to load all these related objects and it would be nice if objects are loaded as soon as they are needed, not earlier. In fact, the fewer objects the system loads – the fewer queries the system makes to the database, and the better SugarCRM performance is, and consequently, the work of the users would be faster and more efficient.

Naturally, the instant loading of the object and all its related records is not always needed and which is clearly non-rational from the point of view of system performance, therefore, it seems logical to fall back on “lazy loading” approach, which allows you to postpone the immediate loading of all related records till the moment when you really need them.

But we should not forget that the implementation of data “lazy loading” onto the already existing system could be quite a complex matter.

2. Deferred operations performing

Some operations initiated by a user could take a long time. But it is not necessary for the user, who is performing the operation to wait until the operation is finished. It could be quite enough for him to receive the notification that the operation is planned to be performed. And when the operation is really finished, a user receives an appropriate notification. Thus, the operations, requested by a user will be performed not immediately, but they will be queued, and then these queued operations will be processed asynchronously by the run of SugarCRM Scheduler. Hence, a user won’t have to wait for the result of operations performing and moreover, such an approach helps a user to make time for critical business tasks.

As applied to the example of saving the results of the call, it should be noted that it is quite more complex operation than it seems to be. This operation indeed consists of the following sub operations:

  • saving the results of the call record itself;
  • setting the relationship between the saved call and certain parent object (i.e. account);
  • generating the Activity Stream records that will reflect the information on who has performed the action, on which record the action has been performed, which parameters have been changed etc.;
  • updating of the current user’s calendar.

All mentioned above requires the loading of huge number of objects and its related data and, consequently, it leads to the huge amount of SQL-queries to the database that, in turn, means that a user can wait for the completion of the operation till doomsday. But how soon the user’s patience will run out? How long should the user wait till the system finishes executing all above mentioned operations to perform a task, which is seemed to be simple?

This is right the case when the deferred operation performing come in play. We can easily place in a queue such resource-intensive operations like generating the Activity Stream and updating the current user’s calendar. As a result the user will receive the information that the call saving operation is finished, but in the meanwhile some related sub-operations continue to be executed.

Using the method of deferred performing of operations, we do not ease the load on the SugarCRM database, it remains to be the same, but the user will be able to see the main advantage of such an approach that is the system fast response to the actions done by user in the system. The disadvantage of this solution is that the user will see the new or updated values of all auxiliary data only after a while.

It is important to note that this approach is applicable in situation when it is not critical for the user to see all the updated data and information as soon as the changes have been saved.

But, on the other hand, while the information is being updated, the user could do a lot of useful work.

3. Caching

Caching is a good way to optimize SugarCRM performance. It implies temporary storing of recently used information in order to make it faster to get the needed data, which helps to improve the work efficiency and overall performance of the system. Caching is quite simple in configuring, and it can speed up the CRM system performance and can save resources. Moreover, it’s much easier to perform the horizontal sizing while implementing caching approach than to increase the size of the bare database.

Out-of-the-box SugarCRM system uses cache for storing metadata and some business data. However, as practice shows, it is possible to achieve a significant improving of system performance by using caching of SugarCRM business data more intensively. It should be noted that caching may be especially useful when the information is requested frequently, but changes relatively infrequently, i.e. the cached data has to be quasi-static.

Which SugarCRM data can be considered to be quasi-static? The answer to this question can be quite different depending on the certain case and requires special consideration, depending on the particular conditions under which the system is used. However, with a great amount of confidence we can say that, in most cases, the following data can be considered as quasi-static:

  • Information on the system users
  • E-mail addresses
  • The names of business entities

Our experience shows that caching of the above mentioned data and information, which is specific to a particular business, allows increasing SugarCRM performance significantly.

In this guide, we’ve covered some of approaches that can solve some system performance issues that you can face while working with relatively large volume of data. These approaches are: lazy loading, deferred operations performing, caching. These approaches were successfully implemented and proven to be quite efficient in our projects:

  • Admiral Markets: the case of integration with trading platform
  • Pigu: the case of integration with ERP system

Basically there are other approaches which could help to deal with “big data” issues but they are out of bounds of this guide.

If you have any questions about SugarCRM performance tuning, please, do not hesitate to contact us:

Leave your details and we’ll get right back to you
First Name

Last Name



I have read the Integros privacy policy and consent to the processing of my personal data.

Leave a Reply

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