Hello!  I'm Justin Kuehlthau (@justinkuehlthau), Director of the Sugar Practice at Technology Advisors (Technology Advisors, Inc.).  This was my 8th SugarCon, and this year I was lucky enough to be selected as a Sugar Scholar! 

One of the interesting sessions I attended was presented by Jorge Arroyo, VP of Engineering and Fellow at SugarCRM, and Alexey Klimko, Senior Software Engineer at SugarCRM.  This session covered planning and architecting for and troubleshooting performance in Sugar.

This break out session started with Jorge discussing performance in Sugar and ways it can be improved.  My favorite quote of the presentation was:

Solutions must be architected and designed for performance.  The #1 element of user experience is performance.  You must plan for it during all phases of your project.

Main Takeaways

Jorge and Alexey split the presentation into two main parts:  performance and troubleshooting.

Performance by Jorge

List Views

List view performance is determined by the database.  The key to list view performance is indices.  If you’re going to sort on a field, you should consider having an index on it.  On the other hand, you do not want too many indices.  As such, you must be judicious with the fields you allow your users to sort on.

When typing in a search, Sugar list views automatically search by your filter after a 300ms pause.  If you type "Arr", pause for more than 300ms, type "oy", pause for more than 300ms, type "a" and then stop in order to search for Arroya, you’ve actually performed 3 searches for 1 search.  The pause delay can be modified via Sugar Config or you can disable the type-ahead search.  List views and search queries are 80% of the load on your instance.

Record Views

To improved Record view performance, only show the information you need.  Every chart in a dashlet in the Intelligence Pane is a report that runs.

Save action performance is affected by Workflows, Logic Hooks or external APIs.  With poor planning, 1 record save can easily be turned into many record saves.

Home Page Dashboards

Be careful when designing your Home Page.  Every chart is a report that runs and every report can potentially be looking at several different modules.  Only show what you need.  If you’re deploying a default Home Page, don’t deploy a default Home Page to all users that has a lot of Reports on it.

Troubleshooting by Alexey

Pay attention to where the issue may be.  A slow client machine cannot run Sugar well because Sugar uses a lot of JavaScript.  Sugar will not run well if there is slow network performance.  PHP runs on the web server, which must be setup properly on a correctly scaled machine.  Finally, it all requires good code.

Things To Check

Use Chrome Developer Tools to determine if Sugar is actually the issue as opposed to the Network.  PC/Browser?  What is the DB Server doing?  (Are other databases hosted on the DB Server?)  What are the slow queries in Sugar?  Review the DB statistics.  Get as many details and facts as possible: Which view? Which action? Specific user? Any page? Specific time? Specific IP? Logs? HW usage graphs? Data volume? 

When all else fails, ask Sugar Support for help.

Use Sugar's XHPROF!

SugarCRM XHProf viewer is an extended viewer based on the standard xhprof viewer by Facebook that shows some additional information like sql and elastic queries, their timing and stack traces. (https://github.com/sugarcrm/xhprof-viewer)

Get their slides

I tried to summarize Jorge and Alexey's big points above, but you can check out their full slide deck here.