Installing and XHProf to profile Drupal on Ubuntu

Filed under: drupal,web development — jaydublu @ 2:48 pm

The following recipe was used to install XHProf on a Ubuntu server running Drupal 6, inspired by http://techportal.ibuildings.com/2009/12/01/profiling-with-xhprof/ – my PEAR installer complained about missing config.m4, and I couldn’t find Brian Mercer’s php5-xhprof Ubuntu package.

Download and manually install XHProf:

wget http://pecl.php.net/get/xhprof-0.9.2.tgz
tar xvf xhprof-0.9.2.tgz
cd ./xhprof-0.9.2/extension/
phpize
./configure --with-php-config=/usr/bin/php-config
make
make install
make test
cd ..
cp -rp xhprof_html /usr/share/php/
cp -rp xhprof_lib /usr/share/php/
mkdir /var/tmp/xhprof
chown www-data /var/tmp/xhprof

Optional – install graphviz for the Callgraph funtionality

apt-get install graphviz

Create /etc/php5/conf.d/xhprof.ini

[xhprof]
extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"

Create/etc/apache2/conf.d/xhprof.conf

alias /xhprof_html "/usr/share/php/xhprof_html/"

Restart Apache

apache2ctl graceful

Configure Drupal in /admin/settings/devel

xhprof directory: /usr/share/php
xhprof URL: /xhprof_html

Now to get my head around what it all means!

To update or not to update

Filed under: life — jaydublu @ 4:11 pm

There’s a sweet contentment knowing that a system is fully up to date and patched, but how uncomfortable it soon becomes when you find out there’s a new update or patch – leading to the nagging question of if / when to go through the grief of updating.

On the one hand, you know you should apply updates as soon as you can to get any potential benefit of new features, bugfixes or even improved security and performance – but anyone who has been around long enough will know that even the simplest patch can upset an otherwise stable system and be a royal pain to resolve.

That leads to the temptation to procrastinate and put off updating systems until it can’t be avoided any longer, but the longer updates are left the more they build up, and the worse the process of updating becomes – again you may hear the sigh of bitter experience?

I’m not just talking about applications like WordPress and Drupal, or the dreaded Windows Update – there are so many constant reminders from all sorts of systems to ‘update now?’ And I’m talking about minor updates rather than the biggies like Vista -> Windows 7 or Drupal 6 -> Drupal 7 – those you have a choice, but minor updates you really don’t, it’s more a matter of ‘when’ than ‘if.

Here is a summary the guidelines that I try and stick to:

Have a regular ‘maintenance period’ – Accept that maintenance is a fact of life, and schedule an appropriate amount of time at least monthly to review logs, apply updates and other housekeeping tasks to maintain a healthy system. Of course this implies that the more systems you look after, the more time will be spent in maintenance, but that cannot be avoided – without tlc systems tend to ask for your attention when it’s not so convenient!

Don’t do updates on a Friday afternoon – As tempting as it may be to slip this task in at the end of the week if your ‘proper work’ allows, it’s tempting fate and if you have problems with an update you might not have enough time to resolve it, or you might shortcut testing and not spot an issue until Monday. Make sure you have set enough time aside to do it properly, and you’re in the right frame of mind.

Design your system to be maintained – when carrying out initial installation and configuration, think ahead to how you are going to apply and test updates and patches, and migrate changes between environments. Good decisions at the start make life so much easier six months down the line. Documentation and good naming conventions are key. And of course as part of your deployment there was a test plan that can be used to validate updates?

Prepare and maintain a documented maintenance procedure – It makes the task much less daunting to know that you have a ‘script’ worked out rather than having to keep re-inventing the wheel. Wikis are ideal for the purpose as they’re easy to create and maintain. Anything you have to spend time figuring out so that next time you don’t have to struggle to remember it, or work it out again. If you find information that’s wrong or missing, fix it, and keep documentation updated as your system evolves.

Read the release notes – try to get an understanding of what the update or patch you’re about to apply will change so you can analyse potential risks and identify any mitigating measures you might take, and to also identify what testing you can do to satisfy yourself all’s OK afterwards.

Once you start – don’t stop until you finish – it’s probably worse half applying updates than not applying them, and even harder to do maintenance next time. So no distractions, and remember the ‘not on Friday afternoon’ rule.

Pat yourself on the back afterwards – it’s a necessary job, so make sure you get your due reward. If you’re doing this for someone else (a client) make sure they appreciate the effort it takes, and don’t be apologetic about taking the time to do it properly. Few people notice a well running system, but you soon get shouted as when it goes titsup, so sleep well in the knowledge that all is right with the world again and you have done a proper job!

Server monitoring

Filed under: review,tinkering — jaydublu @ 5:39 pm

mysql_queries-week MuninI think I’ve finally found an almost perfect suite of tools to monitor webserver performance and availability – it’s only taken five years!

The most recent discovery that has me all excited is Munin – I’d heard of it before but can’t think why I’ve never given it a go. It’s a fantastic tool for recording all sorts of useful metrics in rrdtool stylee graphs – far too much info in fact as it’s bringing out my hypochondriac tendencies.

I’ve been using Nagios for years – although Ubuntu distros make it easier to set up it is still a bit like hard work, but once it’s set up it’s great. I’m using nrpe plugins to remotely monitor many of the same metrics as Munin is recording on a suite of servers, but Nagios is set to generate alerts if they go out of tolerance. Once you get the thresholds right it can warn you of impending trouble before a site actually fails – a theory which actually worked a few weeks back when alerts for page response time and processor load allowed me to take evasive action before a site actually crashed.

I’ve got a utility script or two, such as one which monitors MySQL replication, which is regularly polled by Nagios which triggers an alert if a certain string isn’t found. I’m sure there is a plugin or other cunning way to get Nagios to do this without a script, but this was easy, and it works!

Finally for in-house tools, good old AWStats for logfile analysis gives me an idea of raw traffic served.

For remote tools, I use an email to sms gateway to allow Nagios to alert me of critical problems if I’m not at my machine, for a second opinion and as a safeguard I also subscribe to a remote monitoring service – of the many I’ve tried I favour Alertra, but also use Pingdom occasionally. Finally Google Analytics allows traffic analysis within the site, and that’s about it.

But as the BBC says, other services are also available.

How to liven up a dull blog

Filed under: opinion — jaydublu @ 2:00 pm

WinCacheGrindPerformance problems again, but this time at an application level. So I finally get around to trying out PHP profiling tools in earnest. XDebug and WinCacheGrind give very useful information where a script is spending its time, without having to go dropping bits of benchmarking code around.

I know this is old news – I’ve just not had a real need before now. So I go hunting for good info on how to get the most from WinCacheGrind, and the project’s SourceForge homepage has a really interesting approach to livening up what could otherwise be a slightly dry geeky subject.

Not an approach I would feel adopting long term, but I thought I might try it out just once…