Timing & Knowledge Matter: Load Testing

Timing is everything, as they say, and that's especially true when trying to optimize website performance.

Last time out in this series on load testing, I offered ways to prepare for site visitors of all stripes. This time, let's flip to the other side: back-end operations. Surely, how you maintain and upgrade your site will have just as much sway on site performance as visitors will.

Consider the saving of content. Does it affect performance? It does for many sites. For example, you'll have sites for which load tests were run completely from the user's perspective, but the first time these sites slide, the administrators will try to save a piece of content and hit a contention point. The cache is clear, but something strange has happened that wasn't anticipated.

At Acquia, we've also seen a revision of saved content behave differently than brand new content that was saved. So just remember to test all possible kinds of actions, and do so early in the game, before a site slides.

Deployment can affect traffic, so you need to figure out the best time to schedule updates, changes and the like. Some of our large customers deploy only at night. Some customers deploy a dozen times a day. It depends on the job. Say you're unveiling a brand new theme; then you'll need to clear out all caches and should consider doing the job at a low traffic time. But if you're only fixing a bug, then maybe you can send out a small code change and not worry about it affecting traffic. You just need to carefully consider ahead of time what could happen.

If you schedule load tests for an hour or two, have a developer run a deployment, make some changes, save some content, see what happens, and perform the last background operations, basically anything that's scheduled.

We have a lot of customers who every hour, on the hour, will see glitches in performance. The biggest cause is all the background jobs they have running to sync content or connect to some external Web service. But because many of them setup monitoring early while running load tests, they're able to see these spikes early.

Keep that in mind next time you perform a load test: a service that tracks performance will help. New Relic is one I recommend. During a load test, it allows you to see not just how requests perform from the customer's perspective, but also how the application is performing.

Again, don't wait. Take these steps before a launch so you can catch any problems.

In the next blog post, we'll look at how Drupal 8 makes page caching easier and other things you can expect from the new platform when load testing.