Magento Load Testing – Magento Performance Optimisation Pitfalls

Date: 15th May 2013
Author: Deri Jones

We do a lot of load testing, on a huge variety of platforms from clients like Tesco who use  the big end platforms such as ATG, through scores of sites where we do .Net load testing or Java /WebSphere, and then web-technologies from Ruby to PHP and cool frameworks like Cappuccino.

Magento load testing has become an interesting area, and one where the lesson of ‘premature optimisation’ does matter


Magento Open Source eCommerce

Premature Optimisation is the principle, in software development, that you should not optimise your code until that part of your code has already proven to be the bottleneck.  It’s kind of a scientific, evidence-based, approach: don’t try to guess in advance where your code will need lots of optimisation, and where it will need a little.  Just build it and find out. That way you can optimise what’s needed and be sure you didn’t waste time on optimising something that was not an issue.

In the eCommerce space Magento is a widely used open source platform with a vibrant market of extensions and community of developers to build custom features for you.

It means that, although there are loads of sites all using Magento, that they are mostly all different due to having different combinations of extensions and customisations.

They will all have different Magento performance problems!

So it is that keen tech teams will often, with the best of intentions, spend time making certain changes or bolting on extras such as varnish or cool caches etc with the aim of improving performance.

Only to find the performance may still not be ideal.

A company like us is then sometimes called in to get some new evidence, by doing some genuinely realistic load testing. When we use our classic approach of ‘Do What the Customer Does’, rather than just an artificial website load test, the load testing will often identify a bunch of issues in components  that ‘in theory’ are there to make things faster, but in reality are making them worse!

This could be because the component:

  • addresses a problem that is not such an issue on newer Magento versions,
  • is configured  in a way as to undermine its effectiveness  (a way that may have worked a year or two back),
  • conflicts with custom work or bought in extensions.

These issues are particularly crucial when planning a Magento migration. It’s so easy to introduce Magento performance problems when making the kind of changes that are natural in a  migration:

  • upgrading an extension without thinking about it,
  • doing database memory allocation differently,
  • etc.

Magento performance consultancy, we find, centres round the Best Evidence: the Magento load test.

To conclude: the fastest way to optimise your Magento performance, is about a journey that starts, and continues, with load testing.

And whilst this is true for ATG performance consultancy, or .Net performance consultancy or whatever, it is particularly true in the Magento space due to the mirage that it is a standard platform, when, apart form the simplest site, it never is.

Appendix:  Lists of Magento Tuning  Tips and Tricks

In the car tuning world, there are hundreds of things you can do, from fuel additives to new shocks for faster corners.

But for your specific car, engine, model year, customisations etc you wouldn’t google for them all and try to work your way through one by one!  No, you’d take the car to a race track, and try it out, then you’d put the car on a  ramp and measure raw engine directly, and only then would you start to plan what specific upgrades make specific sense for your specific situation.

The same approach applies to your Magento performance optimisation too, because look how long the list of possible performance improvements are:

  • 3 dimensional: Process/ Transfer / Render
  • OS optimisation
  • Web server config optimisation
  • HTTP header, eTag, cache,expiry
  • database
  • accelerator extensions
  • Magento cache  /clearing
  • Magento CSS/JS merging
  • enable parallel downloading
  • remove unused Magento modules
  • consider flat catalogues
  • PHP compilation and options
  • zero tolerance of 404s
  • Magento Compiler module
  • use a CDN (or homegrown one)
  • Use varnish
  • HTTPS audit
  • SSD or memory file-system usage
  • Apache or nginx or Litespeed
  • Lazyload
  • Log less !  (ouch, some folks  risk making magento trouble-shooting very hard, if they do this)
  • load balancing
  • database replication
  • magento clustering

If you are currently wrestling with a broken down Magento installation then give us a call. We know a man who can!