Sugar is slow - some ideas to improve the speed

[mycrmspacegunnar]

I think a major drawback of Sugar is that is feels quite slow.

A number of things together account for the feeled slowness of Sugar.
These are:
- the time spend on database queries
- php execution time
- template engine
- webpages transmission time to the browser
- icon/css/js/images verification and or transmission times
- rendering time in the browser

For us users its difficult to change the source code of Sugar to run faster.
But luckily, there are a number of ways for us to tune a Sugar installation to increase the speed.
With some server tuning its quite simple to double or triple the speed of Sugar.


2) - the time spend on database queries
The MySQL server has a feature called "Query Cache".
This cache remembers the answer to recently issued queries.
Sugar repeats a lot of queries from page to page.
Activating the query cache in MySQL will significantly improve the database speed.
To activate the query cache set the query_cache_size parameter in the my.cnf config file of MySQL.
E.G. query_cache_size = 32777216
The above line will set the cache size to 32 MB


2) PHP execution time
Sugars source files are big. The PHP compile and execution times are quite high.
Make sure that you install a PHP code cache like eaccelerator or apc to cut down the PHP JIT compile times to zero. Using such a PHP code cache has no drawbacks and will increase the speed of Sugar a lot.


3) Webpages transmission time to the browser
Sugar webpages are quite big, typical size is 100-200 KB per page.
In addition to the dynamic created html pages, there many JS or CSS files which are quite huge. All the files inlcuded in the login page alone are over 500 KB altogether. Downloading this much data simply takes some time. To speed up the download times, activate HTTP content compression in your webserver. When you use Apache this can be done by mod_gzip (or mod_deflate for Apache2).
Content compression will reduce the amount of transfered data by 80%
Compressing of the files will need a little bit CPU resources but this is neglectable.
The heavely reduced time for the download is worth it. You will feel this speed up.

Normally a website might not want to compress JS files to be compatible with some very old webbrowsers (old Netscape version could not handle compressed JS files).
You should enable compression of JS files for Sugar. Sugar does not work with old Netscape versions in the first place - so there is no drawback. And Sugar has many big JS files which will download MUCH faster when compressed.

Example mod_gzip :
mod_gzip_item_include file \.php$
mod_gzip_item_include file \.html$
mod_gzip_item_include file \.js$
mod_gzip_item_include file \.css$


4) icon/css/js/images verification and or transmission times

Sugar themes look nice and contain many small image files.
A typical single Sugar page contains about 40 images and numerous JS and CSS files.
A webbrowser will cache these files, so it will effectively only download them once.
But typically (depending of your cache settings) a webbrowser will verify with every opened Sugar page that the cached image and JS files are still the newest version. This means typically a webbrowser will unneccessarily open 40-50 connnections to the web server per opened Sugar page to verify the cached images.
This wastes a lot of time and puts unneeded load on the webserver.
By hinting the webbrowser that it is allowed to cache the files without constant verifycation, this time can be saved. To enable this hinting, activate mod_expire in Apache.
Adding these lines to your Apache conf will remove the unneeded verifications and feelable speedup sugar:

ExpiresActive On
ExpiresByType image/gif "access plus 3 days"
ExpiresByType image/jpeg "access plus 3 days"
ExpiresByType image/png "access plus 3 days"
ExpiresByType application/x-javascript "access plus 3 days"
ExpiresByType text/css "access plus 3 days"


5) Rendering time in the browser

While compressing the Sugar html pages is a first step to speed up the download of the sugar pages - an advanced alternative is to not send already downloaded pages at all.
This is possible and will reduce the download times to zero, for pages that the users has visited before and which did not change. This will speed up Sugar a lot.

A way how to enable this (including needed source code ) is explained in Sugar bug report 9136
http://www.sugarcrm.com/crm/?option=...1-4511070396fa

I hope that the Sugar team will include this into SugarCRM to speed it up.


I hope that the above is helpfull for some of you.
If you have other tips to speed up Sugar please include them.


Cheers

Gunnar von Boehn
www.mycrmspace.de

[rocketraman]

By hinting the webbrowser that it is allowed to cache the files without constant verifycation, this time can be saved. To enable this hinting, activate mod_expire in Apache.
Adding these lines to your Apache conf will remove the unneeded verifications and feelable speedup sugar:

ExpiresActive On
ExpiresByType image/gif "access plus 3 days"
ExpiresByType image/jpeg "access plus 3 days"
ExpiresByType image/png "access plus 3 days"
ExpiresByType application/x-javascript "access plus 3 days"
ExpiresByType text/css "access plus 3 days"

I don't want to hijack the thread but I can't get javascript and css files to expire this way. I posted earlier on this with some more details:

http://www.sugarcrm.com/forums/showthread.php?t=16607

Cheers,
Raman

[clemens_von_dincklage]

Raman,

Caching of the JS and CSS files is possible with the setting that you and Gunnar have posted here.
If your browser does not cache these files then this is certainly an issue of your browser and not of the webserver settings.

Please mind that IE can be configured NOT to cache any files transmitted over https.
If you are using IE then this might be a reason for your problem.
Typical other causes for caching problems are
a) wrong local time. If your date is wrong then the expired date will most likely not work as expected.
b) usage of Websecurity software that is not standard compliant.
For example: Symantic Norton Internet Security Software is know to be buggy and to have a number of http issues, causing all kinds of problems and slowdowns.


Cheers

[mycrmspacegunnar]

There is another thing which you need to check if you want to make sure that a users webbrowser can correctly cache
the dynamic created webpages of sugar.
The php sessions setting need to allow caching. (PHP default is no caching)

session_cache_limiter("must-revalidate");

Setting the caching to the above (e.g. in index.php) will allow caching
and if you combine this with the above mentioned etag patch then this will give you a very nice speedup.

Cheers

Gunnar von Boehn
www.mycrmspace.de

[WayneSugar]

Great suggestions mycrmspacegunnar.

Also check out our official speed guru, Jacob our CTO's post here:
http://www.sugarcrm.com/forums/showthread.php?t=14126

[czei]

That post from the CTO is from 2004! I went and tried to find some of the speedups, but the Sugar PHP config files look to be substantially different from what is described. How much of that article is still current?

Thanks,

[britesprite]

First up - no-one should be discouraged bu czei's comment -- this CTO thread is now current and up to date. It may not have been when he/she checked it out, but that's a different issue

Me -- I've installed and configured several SugarCRMs in my time and have found the forums an invaluable tool for performance tweaking -- my thanks to everyone for their time and dedication.

One quick question for Gunnar, regarding the etags solution. I've read the "bug" report you've put in with this solution but am still confused as to its implementation. In particular:
a) do all 3 of the steps have to be done to get this up and running? and
b) if not [i.e. my current performance issue is on a hosted server so I can't get at Apache/PHP/MySQL configs] what do I do with the code snippet you've provided .. lob in in the beginning of index.php?

Many Thanks

Chris.

[czei]

"First up - no-one should be discouraged bu czei's comment -- this CTO thread is now current and up to date. It may not have been when he/she checked it out, but that's a different issue."

You mean the old posts to the forum have been retroactively edited to reflect the latest release? It looks like additional posts have been made, but its still unclear which of the posts apply to which versions of the software. Obviously every suggestion for 3.5, for example, won't be applicable to 4.5, but some might be. Its impossible to say with the information given.

Not to be critical, but I don't think its too much to ask SugarCRM to maintain an update-to-date list of performance enhancements.

[cywolf]

Most of the performance tips are still valid for version 4.5 - it does still have mostly the same system requirements after all.

The native PHP JSON encoder was optimized, so there's less need for the C extension.

The biggest change caching-wise since version 3.5 is probably that all CSS and JS includes have the version added to the query string (ie. sugar_3.js?s=4.5.0f&c=), although I'm not sure what impact this would have in different browsers. Also, the javascript representation of application language strings is now cached client- and server-side.

The switch to Smarty templates should help performance through its compilation of templates into PHP code. The switch to UTF-8 strings probably has little impact performance-wise.

[Jacob]

Many of the configuration guidelines posted in the start of the ongoing performance work are still valid and still work just fine.

I have moved most of the suggestions into the wiki for a more collaborative environment and to keep the settings discussed up to date. I try and consolidate feedback, suggestions, and additional configuration options into the wiki.

The forum at this point has digressed into more conversations about different experiences. It is still a very active forum that people are benefiting from.

Wiki Links:
Performance Tweaks from the start of the thread updated
System Configuration Settings
There are also sections for caching, diagnosing issues, slow query logging, ... Check out the Developer Wiki. I keep the performance stuff near the top.

Gunnar, thanks for the suggestions and the excellent write-up. Would you be up for merging the suggestions into the wiki? If not, we can do so.

Thanks,
Jacob