User login
Navigation
Recent blog posts
- Ubuntu mirrors up and improved!
- Google-jstemplate: Iterate object with unknown properties
- nginx https proxypass for php apps
- sugarcrm & memcache: Doing it Wrong
- subversion and https in Ubuntu Karmic
- Drupal: Views block delta converted to md5 hash
- Ubuntu Server install requires PAE
- Installing Drupal from command line
- Drupal: Handling form field weight through CCK
- minify javascript using Google Closure Compiler
angch's location
angch twitter
performance

sugarcrm & memcache: Doing it Wrong
angch — Tue, 09/02/2010 - 12:10
Part one, tl, dr: memcache actually made sugarcrm slower.
Part two, tl, dr: Installing php5-mcrypt makes your sugarcrm site runs faster! Wish they'd note this more prominently.
We reinstalled sugarcrm the other day. Looked okay on development machine. Tested, everyone (for some values of "every") liked it. So we deployed it to the production machine. Used it for a while, then the dashboard and front page promptly slowed down to a crawl, taking up to 10 seconds to display when it was very snappy and loaded in sub-seconds.
After some false starts at troubleshooting, we backported the site back to the development machine. Slow. Okay, time to bring out the heavy duty tools and be serious about it.
1. Get Xdebug up
sudo apt-get install php5-xdebug # If you haven't already
sudo vi /etc/php5/conf.d/xdebug.ini # Or jed. jed is good.Add following to xdebug.ini:
xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp/xdebugSet up the output directory, restart apache:
mkdir /tmp/xdebug
sudo chown www-data /tmp/xdebug
sudo invoked-rc.d apache2 restart... and reload the offending slow sugarcrm page. xdebug spits out the diags at
/tmp/xdebug/cachegrind.out.135822. Cachegrind Analysis
The cachegrind file is a rather raw output, so we'd rather have a pretty GUI to visualize it. We'll use kcachegrind for this.
Rather than installing the GUI on the development server, we disabled xdebug, and copied the cachegrind output to our workstation. sudo apt-get install kcachegrind on our workstation will get us everything we need.
Start it up. (Applications / Programming / KCacheGrind). Load cachegrind.out.13582 that we copied over. Set the display to display absolute time (Right click on the data, "Show absolute cost"):

There. Out of the total runtime of 7.57 seconds (first row), 6.94 seconds is spent on php::Memcache->set. What?
Memcache making things slower? Wait, we didn't configure sugarcrm to use Memcache! Apparently sugarcrm automagically uses memcache if it detects it:
Sugar automatically enables external cache support once it detects a supported external cache method
3. Conclusion & Fix
It's memcache. It has to be. Time to test.
Before stopping memcached:
Server response time: 7.23 seconds.After stopping memcached:
Q.E.D. More permanent fix:
sudo vi config_override.php$GLOBALS['sugar_config']['external_cache_disabled_memcache'] = true;I'm not sure if the problem is related to sugarcrm or the way we set up our server (all signs point to our version of memcache module for php), but this post is more about how we found the problem, and can be used for just about any php app.
P.S. sugarcrm 5.5a, Ubuntu 8.04 LTS (amd64), mysql 5.0.
P.P.S. Spoiler in title, I know.
Part 2: Speed, more speed!
Further testing still showed that our development server is still faster than production. More testing showed that the both development and production server called Sugar's PEAR's Blowfish routines(why sugarcrm is crypting so many things is beyond me) alot, but the development machine runs those faster. Hmmm.
Further looking at the source code, PEAR's blowfish has a Blowfish implementation in PHP as a fallback in case it can't load the mcrypt module for php. Installing php5-mcrypt and restarting the webserver fixed that.

Revisiting Linux swap space size calculations
angch — Wed, 29/07/2009 - 21:33
Back in the early days of Linux, the rule of thumb for sizing your swap partition is "twice the amount of RAM". But does that still apply to modern hardware where we regularly have 16 GB or more?
4 schools of thought:
- $ram * 2 (I call it the "jurassic" method)
- $ram > 2048 ? $ram + 2048 : $ram * 2 (aka "redhat", see below)
- $ram <= 2 GB ? 1.5 * $ram : ($ram <= 8 GB ? $ram : 0.75 * $ram) (aka "oracle", see below)
- 4GB (I call it "angch's")
Last school of thought is mine, and the rationale behind it includes:

Drupal: PostgreSQL vs MySQL
angch — Thu, 26/03/2009 - 19:11
Let's get this out of the way first: MySQL beats PostgreSQL for Drupal sites in terms of raw performance. See this benchmark
But the real question is the how and why, and also how to make sites even faster and more scalable?

Dogfood, cobbler's kids, changes to blog.bytecraft.com.my
angch — Fri, 20/03/2009 - 13:16
Haven't been working on this site (blog.bytecraft.com.my) for a while. There are plenty of things that needs to be done, and while it's not perfect:
This site is based on our pulut's Drupal 6 branch. Easier to maintain several sites with well known and tested modules.
Changed the theme to Acquia's Marina. Still needs some tweaks to css for our content.
Experimenting with Drupal's cacherouter with memcache to speed things up.
Tweaked the PostgreSQL config a little (fsync is slow, asynchronous commit is a Good Thing). Yes, using MySQL for drupal would be faster, but it's dogfood, and we're more comfortable with PostgreSQL.
Added the lego logo.

asynchronous javascripts load
helmi — Fri, 20/03/2009 - 11:53
if you want
better user experience
more revenue
reduced operating expenses
the strategy is clear
Even Faster Web Sites
- from slides Even Faster Web Sites
