We have just posted a Developer Survey for the Sugar Community and are asking all SugarCRM developers to give us your feedback. Please take a few minutes to fill out the survey and let us know what tools and resources you would like us to work on next for you.
Man, giving a talk remote is always hard. Is my mic too soft? Can they hear me? Did some poor guy with a hearing aid just have it blown out ’cause I had my mic too loud? Am I pacing ok? What about handling questions?
Well, thanks to the expert help of Susie and Clint, I didn’t have to worry about any of this while giving my talk on Tuning Sugar Databases to SDUG. Everything functioned smoothly and the only thing I had to worry about was pacing myself, which seemed to work out good. Hopefully those who attended picked up a few new tricks. For those who didn’t get to attend live, we’ll have a recording of the webinar online soon. I’ll update when we do.
I promised some links during the presentation, so here you go. Our wiki is online @ http://www.sugarcrm.com/wiki/. There’s excellent info throughout the wiki, but the settings I touched on specifically are all outlined in Performance Tweaks for Large Systems, except one. Someone mentioned that there was no reference to $calculate_response_time on the wiki, that is correct and will be fixed. In meantime, here’s a quick intro to it. Adding the following line to your config.php:
"calculate_response_time" = true,
Will get you output like:
The other links I mentioned where, in no particular order:
Also, for anyone who’s interested, the MySQL AB tool for automating many of the processes I outlined is MySQL Enterprise. If you’re short on people or expertise, outsourcing your DBA duties to the company that created MySQL is a great option.
Hope that helps get you started on tuning your SugarCRM installs on MySQL. If you have any questions that we didn’t get covered in the presentation or Q & A, post them here and we’ll get you answers.
The next Sugar Developer User Group webinar will be held on Wednesday, March 19th, 2008 at 10AM Pacific Time.
Join Sugar database expert Travis Swicegood as he discusses database tuning tips and tricks for Sugar.
For more information, or to register for this free event, please visit this link.
My good friend and cohort in CRM blogging, Martin Schneider, posted a review yesterday about a recent article from Psychology Today that analyzes why developers participate in open source communities. While I agree with Martin’s thoughts, I think the motivations go a bit deeper…right into the wallet.
First, let’s take the “street cred” idea a bit further. What I’ve seen in the Sugar community is that independent consultants and system integration firms can turn “street cred” into “business cred” or marketability and make some money. Simply put, companies hire you for projects if you are a credible Sugar community member. Also, IT developers NEED to have open source experience on their resumes these days to get the best jobs. Hiring somebody who actually contributes code to an open source project gives companies real competitive advantage for their business.
So being a prominent member of the Sugar community turns into actual dollars (Euros, kroners, Linden dollars, whatever). That’s a VERY powerful concept that is glossed over with the ticky tacky term “street cred”.
Now let’s take the “self-actualization” idea. Yeah, coders code because they like to code. Coding is cool. Believe it or not, one of my favorite ways of relaxing is to fix bugs in Sugar. Now call me wacko (my wife calls me other things), but Sugar is my baby and I want to see her not just sing, but friggen Rock the Cazbah (shout out to John’s current favorite band). So I certainly agree with the point on “self-actualization.”
However, the ability for a company, a project manager and/or a developer implementing SugarCRM to take control of their own destiny around the Sugar app is HUGE. I’ve project managed implementations of proprietary CRM systems in past lives. There’s nothing better at blowing up your project schedule than a showstopper bug or unexpected limitation in an API.
With open source, a company can fix the problem themselves if needed or extend an API to meet their needs. Now SugarCRM works very hard as a company to respond to all of our customer’s reported issues in a timely manner, but when your go-live date is looming ahead of you and your CEO demands no delays, there is nothing better than having the ability to fix any issues yourself and not be tied to the responsiveness of your vendor. And if you are an independent consultant or system integration firm, time = money. Again, control is a very powerful aspect which drives developers to open source that goes way beyond “self-actualization” or even “altruism”. It drives sanity for the developer and bottom-line value for the business.
Personally, I think these two ideas of marketability and control should have been included in the Psychology Today as these are the motivations I hear about everyday from Sugar community members. And marketability is about putting money in your wallet and control is about keeping money from flowing out of your wallet.
A couple recent performance benchmark reports have been written that use SugarCRM as the test app. Both reports are focused on benchmarking specific environments and only use SugarCRM as the test app, but they do give you a good idea of the scale possible with SugarCRM.
From the report…
Conclusion
In our tests we found that the Sun’s Coolthreads server can scale to large number of concurrent users on a single server running both SugarCRM and MySQL. There is not much performance impact if the MySQL is run inside Solaris Containers vs running it in the global zone along with SugarCRM. At 700 concurrent user load we only saw 15% of the network bandwidth used and still left with enough cpu cycles. Sun’s Coolthreads server does scale well with the SAMP stack based applications more specifically SugarCRM and MySQL database.
From the report…
Conclusion
Under the conditions tested, the reference application (SugarCRM) showed a 14% decrease in total user capacity when running in a virtual machine (decreasing from 35 users to 30). At the peak capacity of the virtual machine (30 users), the average page duration was 1.57 seconds, whereas the average page duration of the physical machine at the same load level was 0.97 seconds. Compared at that level, the average page duration for the virtual machine increased 61% over the same load on the physical machine.Since most applications only run occasionally at full capacity, it is worth also analyzing the performance of the system at a lower level of load. At 21 users (60% of the full capacity of the physical machine, 70% of virtualized capacity), the average page duration was 0.84 seconds for the physical machine and 1.00 seconds for the virtual machine – an increase of only 19%. For our reference application, this difference (0.16 seconds) is unlikely to be noticed by the average user.
Both reports have really useful information if you’re interested in the details of SugarCRM scalability and performance. It’s great to see SugarCRM becoming a default test app for these different scenarios. Enjoy!