SugarCRM is one of the world's biggest CRM software applications. It is used because it is open source and can be programmed to each user's specifications. However, one knock against Sugar has been slow response time. That's not to say that the other proprietary CRM's are faster, it's just something I've noticed while working with the product.
As a first, since I haven't seen an article on this anywhere in all my dashing around the Internet looking for Sugar technical information, I thought I would profile Sugar, and show you why Sugar sometimes is slow.
What is profiling? Profiling is a snapshot of an event in an application. It tracks how much time it takes to run each class, subclass, and method. How many times a file, class, or method is called in the course of carrying out the event. It is a dynamic snapshot of what transpired in your application when you click a button.
By profiling you can measure how much memory is used, what files were used, what functions were run, and how many times that function was run. It allows you to drill down into each task to get to the source code that is running slow. Pretty nifty.
The picture below is from saving a detail view in Sugar. What takes the most time, of course, is Sugar core code. The number one culprit is the SugarBean. It looks like Sugar first retrieves the data, and then places the new data in the database. This takes about 170 msecs. Working with the vardef file takes 148 msec. Remember the vardef file defines the ORM connection between Sugar and the database. One particular call SugarBean->SugarBean is called 1011 times, ouch.
If your having trouble seeing this, I would encourage you to do your own profiling, where the results are easier viewed, and worked. To that end, I will do a couple of articles to show you how to profile coming in the next couple of weeks. In the meantime, you can click on the picture, expand it, that may help.
We can drill into one of those vardef calls, vardefManager::refreshVardefs, which takes 56 msecs, another dog.
In drilling into this method, we find that a load of files are included, all from cache. This tells me that on viewing a detail view a bunch of cache files need to be loaded before you can display the view. It appears what the SugarCRM folks have done is try to boost performance by caching everything. This involves a lot of overhead, for in this case, to me, minimal results.
Which brings me to cache, Sugar caches everything. If you make a change in Sugar and can't figure out why your change isn't showing up, there's a good chance the culprit is cache.
You can delete the entire cache folder, and Sugar will recreate it. The first time you do this is a little scary, because its very close to the custom folder that you have to be careful not to delete, but not to worry, blow that sucker away, and watch your code changes miraculously appear.
From profiling this application, I've come to the conclusion that the way Sugar caches, and retrieves the Bean causes most of the performance delays in Sugar. You can bring this home, by running the $SugarBean->SugarBean in print_r, or better yet my NewChk variable checker, available for download by clicking the link in the sidebar. The amount of information retrieved by the Bean is ridiculous. It just about retrieves the entire database, and that's every time a new page is clicked on.
I find that Sugar takes the "gorilla approach", that is, it pulls back everything in the world that a user may need, and puts it in the Bean on every call, and caches everything on the save, instead of the "David" approach of selectively only bringing back what is needed, or caching what is needed, and no more. Admittedly, this would take much more effort in coding the application. I'll get more in depth on the Sugar Bean in future articles.
This is not an indictment of ORMs, but it's an indictment of how its done in Sugar. As a disclaimer, because of the complex relations in Sugar, this may be the best course of action, but there ought to be a better way.
In closing, I thought I'd show you another way to profile. This view shows you each method run, and in a neat graphical format, how much time it takes, and in the bottom window, how it is linked in the application. More on this in future posts.