LinkBack URL
About LinkBacks
Ongoing Performance Work...
Sugar is very committed to ensuring that you get top performance out of the system. Several months ago, we instituted a policy of doing a performance sanity check before every release. We run some base cases in the old version and the new version to make sure that the performance line is held steady or improved.
Recently, we have been working on more aggressive measures to improve performance. While many of these have been shared in the forums, we are documenting these performance improvements in more detail and will make that available soon. There are currently many ways to boost the performance of the system with little or no changes to the end user UI.
The forums have also been a great source of feedback on the performance of the product and your active participation has helped us isolate and remove slow areas of the application.
Some of the third party modules included in Sugar definitely contribute to the amount of processing required to render the application. Where we can identify these components, we provide alternatives as quickly as we can. One example is the JSON encoding that is done in PHP code. It turns out that character by character encoding and encryption is not one of PHP's strong suits. One of the performance tweaks is to load a PHP module that performs the encoding in C++. This results in a roughly 50% decrease in the total response time required to render the list and detail views.
We are definately working on improving the performance, stability, and scalability of the application. I am very interested in any feedback on where things are slow, what could be improved, what is working, and where you have seen improvements.
Below are some of the available settings that improve the performance of Sugar installations. I will follow up this post with some configuration guidelines for Apache and PHP.
Jacob
Here is a quick list of the high level performance tweaks. Many of these are OOB in 4.2.0x but several have been back ported to 4.0.x.
JSON Encoding Module
Version 4.2.0+ will automatically leverage a JSON module. For 4.0.x, please change the top of the encode function in include/JSON.php:
- Mentioned in PHP Configuration. Offloads a lot of CPU from Web Server Platform Requirements
function encode($var)
{
//START JSON MODULE ADDED CODE
// use php-json c library extension if available [ http://aurore.net/projects/php-json/ ]
static $function_exists = null;
if(!isset($function_exists))
{
$function_exists = function_exists('json_encode');
}
if($function_exists) return json_encode($var);
//END JSON MODULE ADDED CODE
switch(gettype($var)) {
Drop the absolute totals from list views
Configuration change in config.php or config_override.php:
- Users see record count 1-20 of 21+ instead of 1-20 of 12984832.
- Most users don't care.
- Major improvement in DB performance
'disable_count_query' => true,
Disable DetailView VCR Control (4.2.1+)
Configuration change in config.php or config_override.php:
- Removes the ability to page through records from the detail vaiew.
- Very few users even know this functionality exists
- Removes the cost of a listview from the DetailView
'disable_vcr' => true,
Collapse Unused Sub-Panels
Configuration change in config.php or config_override.php:
- Greatly Decreases Processing Required to Render the Page.
- We don't retrieve information for hidden sub-panels. Users can expand them as they desire.
// Always hide subpanels when a user views a detail record
$sugar_config['hide_subpanels'] = true;
//When a user first visits a detail view hide all subpanels for a
module. Then whatever subpanels are opened in that module stay open
throughout the session regardless of what the record id is.
$sugar_config['hide_subpanels_on_login'] = true;
Don't Automatically Repeat Previous Query on List Views
Configuration change in config.php or config_override.php:
- This change requires users to hit the search button or perform some other action for the list view to populate records.
- Typically the results of the previous search would be the wrong data anyways.
- Unfiltered seraches are really expensive and show the first 20 records of possibly millions.
'save_query' => 'populate_only',
Use a PHP Session Cache
- Saving and loading sessions can take a lot of time. Storing the sessions in memory or on a RAM disk can definately decrease some of the disk IO wait times in the application. Cluster aware PHP accelerators can store sessions in memory without loss of high availability.
Bookmarks