Improving SugarCRM client-side performance: The server

sugarcrmdevelopers —  July 25, 2011 — 8 Comments

This is the second part in a three part series talking about client-side performance in SugarCRM. In the first part of the series, we looked at how browser choice makes an impact on the client experience, as newer browsers are more optimized for the rich web application experience provided by SugarCRM. In this post, we’ll take a look at how to optimize your web server for better performance.

How to define success

When it comes to server-side performance, there’s lots you can do. Many of these things are pretty darn simple, others can be very tricky. Some are big wins, other small wins, and most could go either way depending upon how your Sugar instance is used. I think the best recommendation is to try some of these suggestions and see if that brings you the performance you and your users are comfortable with. Start with the simple things and build from there, and at each step evaluate the performance changes and implications so you can determine what’s right for you.

So with that said, let’s look at what we can do.

Optimize PHP

The most simple thing you can do is to make sure you are running the most current version of PHP ( 5.3.6 as of this writing ) along with an opcode cache such as APC or Wincache. I wrote a great article a few months back on IBM Developerworks where I talked about the importance of opcode caching, and how it alone can give your PHP application massive performance gains.

Other items to think about here:

  • Optimize the settings in your php.ini file ( again the IBM DeveloperWorks article I did has some good recommendations here ).
  • If you are running on Windows/IIS, use FastCGI and the non-thread-safe PHP binaries for best performance ( some stats on this are here )
  • Remove any directories not needed from the include_path directive, as this will reduce file system requests.


No matter which database you may be using ( MySQL, SQL Server, or Oracle ), improper indexing of database tables usually is the biggest problem plaguing most SugarCRM instances. Each database has a way in tracking queries that aren’t using indexes; for example in MySQL you can use the slow query log to determine which queries are taking the most amount of time and then figure out how to optimize the database to run them more efficiently.

There’s a few other things to consider to:

  • Try to keep your database server on a different machine than your web server. Database servers like lots of memory and CPU, and having other processes steal this ( like web servers tend to do ) can definitely slow things down.
  • If you are using MySQL, pay attention to several settings, such as the query cache, which tweaking can make a huge difference in performance depending upon your server environment and load.
  • If you are using Sugar Enterprise or Ultimate, you can configure a slave database to help speed up the Reports module and keep the rest of the app running smoothly when users are running reports.

Web Server

There are a couple things you are going to want your web server to do to help optimize Sugar performance.

  • Compress most content being sent to the browser
  • Tell the browser to keep things in cache as long as possible for content we don’t expect to change often ( namely Javascript, CSS, and image files )
  • Not to waste it’s time checking things that don’t matter ( like checking for .htaccess files on Apache )

This is one area where your mileage will definitely vary, and your environment will determine the best course of action. I asked around internal about what recommendations people have, and had someone give me some Apache configuration file settings they used for hosting Sugar. Here it they are:

Compression settings:

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/x-js text/x-javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|rar|zip|pdf)$ no-gzip dont-vary
Header append Vary User-Agent

We also override the expire headers directly from Apache to keep stuff longer in client cache:

ExpiresActive On
ExpiresDefault A86400
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000

If you want to debug the compression results, you can add the following to your apache config:

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
SetEnvIf Request_URI .gif image-request
SetEnvIf Request_URI .png image-request
SetEnvIf Request_URI .jpg image-request
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
CustomLog /var/log/apache2/itconnect-deflate_log deflate env=!image-request

This will print out in your logs something like this:

GET /goodies/clean/index.php?entryPoint=getYUIComboFile&3.0.0/build/node-menunav/assets/skins/sam/node-menunav.css&3.0.0/build/widget/assets/skins/sam/widget.css&3.0.0/build/widget/assets/skins/sam/widget-stack.css&3.0.0/build/overlay/assets/skins/sam/overlay.css& HTTP/1.1" 1356/6336 (21%)

I also recommend to disable .htaccess (AllowOverride None) and add the contents of .htaccess delivered by Sugar directly in the directory declaration. This avoids the server to scan for .htaccess files which is  (see

<Directory "/home/itconnect/web">
Options None
AllowOverride None
Order allow,deny
Allow from all

RedirectMatch 403 (?i).*.log$
RedirectMatch 403 (?i)/+not_imported_.*.txt
RedirectMatch 403 (?i)/+(soap|cache|xtemplate|data|examples|include|log4php|metadata|modules)/+.*.(php|tpl)
RedirectMatch 403 (?i)/+emailmandelivery.php
RedirectMatch 403 (?i)/+cache/+upload
RedirectMatch 403 (?i)/+cache/+diagnostic
RedirectMatch 403 (?i)/+files.md5$

(*) If the customer does not wish to enable caching of SSL pages, the content will still be cached in memory if these two are set (which should be by default)

A little note on client caching: to avoid using public cache on the client side, one can set the “Cache-control” header to “private” on each server response with mod_header instructing the browser to use a non-shared cache location for the current user. The getImage.php en getYUIcomboFile.php in example already set this Cache-control header to private. This however has nothing to do with performance anymore.

I hope this helps provide some insight on how to optimize your web server configuration when hosting SugarCRM. Stay tuned for next time where we will look at how the team at SugarCRM is working hard to improve that experience.

8 responses to Improving SugarCRM client-side performance: The server


    …and if You played with “Log Level” dropdown and “Developer Mode” checkbox, don’t forget to reset them to their original values (Fatal only and unchecked), before going production…

Trackbacks and Pingbacks:

  1. SugarCRM Developer Blog » Blog Archive » Improving SugarCRM client … : FRIENDDAT BLOG - July 25, 2011

    […] more here: SugarCRM Developer Blog » Blog Archive » Improving SugarCRM client … Category: TipsTags: biggest > database-tables > include-path > matter-which > Oracle > PHP > […]

  2. Optimizing Your Server | Faye Business Systems Group, Inc. - August 1, 2011

    […] Improving SugarCRM client-side performance: The server Share and Enjoy: […]

  3. Performance issue in index.php - SugarCRM Forums - August 31, 2011

    […] […]

  4. MySQL Configuration - SugarCRM Forums - September 30, 2011

    […] […]

  5. SugarCRM Developer Blog » Blog Archive » Improving SugarCRM client-side performance: The SugarCRM AjaxUI - September 30, 2011

    […] about improving the SugarCRM client side user experience. Previous parts of the series focused on server side and client side performance and what can be done to improve things. In this part, Senior Engineer […]

  6. CRM's account page takes long time to load - SugarCRM Forums - October 26, 2011

    […] […]

  7. Improving SugarCRM Performance | Faye Business Systems Group, Inc. - July 30, 2012

    […]… […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s