Scaling Guidelines

bsoremsugar —  April 2, 2009 — 6 Comments

One thing I have learned from my Professional Services & Support experiences was: performance is critical for a great user experience.

As PHP/SugarCRM engineers, we must keep in our minds at all times the best practices for scalability, high availability, and speed.  For example, we learned a lesson when we initially created the Emails module.  We stored every email message in the database. Well guess what, that works great for 1 user… maybe even 10 users.  But, when it’s a company of 100 or 1000 or 10,000, that model didn’t scale well and it resulted in our rewrite for Emails in 5.0.

The email module scales better now and it’s because scaling was in the forefront of our mind.  Performance engineering is an important part in our development process.

So when I saw this article on one of my favorite blogs, I thought I share it with you.  The author, Haytham El-fadee, wrote excellent guidelines that we should always be thinking about when we code. While most of his blog posts deal with programming languages not relevant to SugarCRM, the Art of Scalability is relevant to all of us.

6 responses to Scaling Guidelines

  1. 

    Nice article, thanks.

    You know, I’m curious to know whether efficient coding is anywhere in the top 5 priorities of the Sugar team. As far as I can tell, all lots of things could be better. Sometimes I see code _so_ bloated (or actually executed two or more times, like subpanel queries), that somewhere last year I concluded that it’s not a major point of Sugar to be scalable. Now if you would like to change this perception we have to spend more time on stuff other then features and functional bugs.

    SugarCRM has major potential in terms of optimization.

  2. 

    @Loek van Gool Yeah. Thanks for the good fodder for more posts :) I’ll ask the dev team what their priorities are. That would make a good blog post.

    As for bloat, there is always room for improvement, refactoring, and better performance. This will also make a good blog post. If you have a particular area of improvement, I’m *very* interested in talking more about it.

  3. 

    @Loek van Gool Yeah. Thanks for the good fodder for more posts :) I’ll ask the dev team what their priorities are. That would make a good blog post.

    As for bloat, there is always room for improvement, refactoring, and better performance. This will also make a good blog post. If you have a particular area of improvement, I’m *very* interested in talking more about it.

  4. 
    Matias Barletta April 19, 2009 at 11:13 pm

    Well I will say there is a lot of improvements in queries.
    We have a few system with a 200 thousand customer base and is SO slow switching from one tab to another.

    Its been 2 years now and Sugar has been great I must say, but scalability is a concern… 100 users, almost 300 thousand opportunities and system is getting slower!..

    What we did is to tweak queries… Group By with Order By has been killing the database.. a simple click in the opportunities tab will do a count(*) in the 300+th. records and then a top 21 order by … thats now around 30 to 60 seconds in MSSQL and a little less in MySQL…

    I think there is room for improvement in speed and scalability… a few options in the admin section to Turn ON/OFF a few things will make the difference…

    thanks again for the great product and the good attitude :)

    MRB

  5. 
    Matias Barletta April 19, 2009 at 3:13 pm

    Well I will say there is a lot of improvements in queries.
    We have a few system with a 200 thousand customer base and is SO slow switching from one tab to another.

    Its been 2 years now and Sugar has been great I must say, but scalability is a concern… 100 users, almost 300 thousand opportunities and system is getting slower!..

    What we did is to tweak queries… Group By with Order By has been killing the database.. a simple click in the opportunities tab will do a count(*) in the 300+th. records and then a top 21 order by … thats now around 30 to 60 seconds in MSSQL and a little less in MySQL…

    I think there is room for improvement in speed and scalability… a few options in the admin section to Turn ON/OFF a few things will make the difference…

    thanks again for the great product and the good attitude :)

    MRB

  6. 

    Nice article, thanks.You know, I'm curious to know whether efficient coding is anywhere in the top 5 priorities of the Sugar team. As far as I can tell, all lots of things could be better. Sometimes I see code _so_ bloated (or actually executed two or more times, like subpanel queries), that somewhere last year I concluded that it's not a major point of Sugar to be scalable. Now if you would like to change this perception we have to spend more time on stuff other then features and functional bugs.SugarCRM has major potential in terms of optimization.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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