Performance: Better to use FastCGI or mod_php?

Hi everybody,

one of our customers instances (Sugar 7.6 Pro) tends to keep getting slower as user base and data size grow, but I cannot pinpoint the source.

I have taken all the measures from the performance guide (no developer mode, not too many list items, no trackers, use Chrome, logging on FATAL, Opcache is in use), optimized the database just fine (running on its own server, no slow queries, InnoDB and Query caches, etc), the Apache webserver ist running the latest supported version of PHP (5.4) and we have only limited scheduler jobs running.

But still the system responds not too quickly, opening a record in the contacts takes nearly 4s.

We are using mod_php for our installation, is there any performance benfit fpr using FastCGI with SugarCRM 7?

On the other hand, I ran some performance test with Chrome, and it seems that nearly 3/4 of the page loading time is used for Scripting:

Clipboard_2016-02-01_18-37-13.png

My client pc is pretty decent (Core i5, 8GB RAM, running Win 7 / Chrome from a SSD drive), so I suspect not much I can do here. Any other ideas where to look?

Greets,

Mark

  • I would say that your Contact record spends a lot of time rendering the view.  Are there customizations to the Contacts module that could cause the Record view there to be re-rendered multiple times?  Do other modules (like Accounts, Cases, etc) have similar performance characteristics?

    App Ecosystem @ SugarCRM

  • I used the complete page reload when starting the performance measurement, so you might have a point here. The Sugar instance has some additional fields and 3 addtional modules that are related to the contacts, so nothing out of the ordinary. Accounts, Leads and Calls (which has only notes as a subpanel) share the same loading times.

  • Ahh, yeah.  Full page reload is going to incur a JS hit as the app gets re-initialized and page gets re-rendered from scratch.  This is a limitation of single page applications. If you are clicking through application, (opening list view > select a record > edit > save, etc) then these operation are typically faster.

    An end to end monitoring tool like New Relic can help identify the hotspots where users are having performance challenges. It allows you to set acceptable thresholds for requests that are used for detailed logging and reporting.  Sugar 7 has built in support for New Relic.

    https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_7.6/Performance_Tuning/Integrating_Suga…)

    To your original question of mod_php versus FastCGI, I do not think I've seen a definitive recommendation.  I know that FastCGI is more typically seen with IIS on Windows for Sugar deployments.

    App Ecosystem @ SugarCRM

  • Hi Matt,

    until recently, this question also was a no-brainer for me. But one of our newest customers provided a server for SugarCRM based on Apache running PHP fcgid, and it turns out to be the fastest Sugar 7 installation I ever saw.

    It also has the Sugar database and core data (webroot without uploads and logs) stored on a seperate SSD storage, but the extremely fast loading times got me thinking.

    @all, if anybody has a thought to share about this, feel free to. If I can spare some time for it, I might try giving this a test run.

    Greets

    Mark

  • In my experience, that SSD storage probably helped quite a bit.  Disk I/O performance is a big factor for Sugar hosting. We use SSD wherever possible in our hosting environments.

    App Ecosystem @ SugarCRM

  • Second on Matt's comments about SSD, it definitely helps, especially at the DB level.

    A couple of other thoughts come to mind that I didn't see mentioned.

    First, there are multiple layers of caching that can all help performance. Opcode caching will help with the execution of the PHP scripts (and should be set to 3x the size of your Sugar directory - minus contents of ./upload), but there is also a user cache and the PHP sessions themselves.

    Are you using Redis, Memcache or similar technology for your PHP session management? If not, it is worth considering. As for the user cache, you could always combine APCu with Zend Opcache to get the user and opcode caching.

    On the Apache side, I would double check to make sure that you have mod_deflate enabled and configured to handle the following mime types:

    <IfModule mod_deflate.c>

      AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript application/javascript application/json

    </IfModule>

    If your are using a load balancer, it is worth checking out if it can do the HTTP compression for you instead of using mod_deflate as it would take some load off the Apache server.

    Lastly on the Apache side, you might want to check the number of available servers/processes it is configured to make available. If your system resources allow it, you should increase those values.

    JSMin is a PHP extension worth looking at as well. You can install it via PECL and once installed, it should help reduce some of the time necessary for rebuilding your ./cache folder contents whenever you have a need to do so.

    With regards to using FastCGI versus Apache 2 Handler, etc., I have seen a mix of all of various handlers being used and can't say that I would bet on one as being the definitive source of improved performance. For example, I work rather closely with a large customer that uses php-fpm and their performance is pretty much on par as another similarly sized customer that uses the more common Apache 2 handler. Even within the broader PHP community there seems to be a lot of debating, and no definitive info, relating to using one versus the other, which also usually bleeds into discussions about using thread-safe versus non-thread-safe versions of PHP.

    Other than using SSDs, can you share more info about the hardware used for each layer? How many CPUs? RAM?

  • For what it's worth, we moved our database to SSD just recently (SugarCRM Pro 7.6.1) and the difference is quite noticeable.

    To give some perspective, we have 1M Accounts and 2M Contacts.

    HTH

    FrancescaS

  • Hi Angel,

    from my experience, I can only agree regarding php-fpm and mod_php, but I was interested in others opinions on that matter, too.Your other suggestions are a great overview. Do you have any more information or tutorial for sessions management? It is one of those things we yet have to integrate.

    There is no specific system we have to optimize for better performance, my intention is to collect some best practices for hosting SugarCRM as Sugar itself is a little shy for information about it.

    Greets,

    Mark

  • There really isn't much to setting up memcache/Redis for session management to be honest. It is all done at the PHP level.

    You would typically install the memcache or Redis PHP extension, then you would configure the session.save_handler and session.save_path parameters in your PHP.ini to indicate memcache or Redis and the memcache/Redis server address respectively. Restart Apache and that's it.

    Here is an example that speaks to the subject as it relates to memcache: PHP Sessions in Memcached - MDLog:/sysadmin

  • I would suggest upgrading to Sugar v7.7.1 and PHP 5.6 due to massive speed improvements with that version.

    .

    CRM Business Consultant