A lesson in performance testing

Submitted by exaboy on Thu, 11/20/2014 - 22:26
A lesson in performance testing

If you've never performance tested a website before stop what you are doing, if you have, do the same. I'm pretty sure you're doing it wrong and wasting everyone's time.

To performance test a Drupal website correctly you need a number of things:

patience
a crawler
a spreadsheet
a browser
There are a couple of facts you need to understand.

Your application is going to get slower the more load you place on it
Your application can only handle so much load before it needs to scale
Caching the life out of everything delays the above two points
Cache everything, and make sure everything is caching. Seriously, everything has the ability to be cached but I can guarantee you something is falling through the cracks and it will be your downfall. You need to understand your caching strategy; know how long everything should cache for, know what has the longest, and the shortest cache lifetimes. This knowledge means you know where your weakness lies.

If you have an area of the site that requires a low cache lifetime your performance tests will need to gravitate towards this area, since that is also where your visitors will flock, right? Interesting relationship huh? But hold your horses we are not done yet. What happens when your pages are regenerated is just as important. We are still talking about cache, because there are things we can cache that in some cases it will outlive many page rebuilds.

What I am getting at here is that caching is like an onion, or an ogre, it has layers. Explore this idea and cache everything you possibly can, and store it in cache-friendly places like Memcached, not the Database or the File-system.

Back to performance testing. The first thing you will want to do is crawl your site, why, because you need to hit every single page to ensure what is supposed to cache, actually does. Trust me we don't want surprises, oh, and make sure that you check the dynamic elements and the form callbacks on the pages also, these can shock. Next thing is to go over all your main sections with your Developer toolbar open at the 'network' tab. Look for all the javascript calls made and see if any call back to your site. You will have to likely click around too. Oh what was that, you have forms with POST when they could be GET, brilliant! Now go fix it. Run over the access logs to see what pages fell through the cracks and resolve the caching issue.

At this point, if you have followed what I've said, you are at least 25% likely to pass the performance test, well more likely 40%, because you've saved yourself a ton of work already. Now comes the fun part, designing your performance test plan. If this application is replacing an existing one you have an advantage since you know the levels of traffic, but even then it's not like for like, I doubt you've just poured your life into a project to end up with the exact same thing. So it's a rough guide, because again, the site might be even more popular than before, so we need to account for that.

I've done a lot of talking, now would be a good time to get a coffee, a beer, or have a scratch. Just don't check your email or its all over.

You have likely solved yourself a lot of work with this exercise, and all without running a single performance test. Well done you. Make sure you document all you find wrong and how you fixed it because this can help you and others later.