So what makes us the fastest Magento host then ...

As we've been developing Magento sites for almost a year now, I think we can start to say we're getting proficient at the inner workings. So much so, that with our expanding hosting range - we've been tweaking our server to squeeze the best possible performance out of Magento.

What looks to have been an uphill struggle for most, after a good few weeks of userspace tweaking, we've gotten the best consistent performance from our installs now. So I thought I might let you guys in on how to get a little more out of your current server - then when you want more performance, try out our Magento consultancy offerings.

First, its best to point people to https://www.magentocommerce.com/boards/viewthread/9037/, it hits the nail on the head for a lot of key points. Then for a quick follow up read this, https://www.magentocommerce.com/boards/viewthread/36225/. But I'm going to rule out any optimisations in that list that didn't have any effect (at all).

  • Fooman Speedster This will speed up the users experience, but actually causes unintelligent benchmarks (like Siege and AB) to give worse results.
  • Enable gZip There is a trade-off here, but it is more than acceptable. There is a mild CPU impact for the compression process, however, the improvement in delivery speed to the client far outweighs it and results in a much higher rate of transactions.
  • Install eAccelerator We tried them all, extensively. For Magento - this is by far the best performer.
  • Turn keepalives on The theory on KA is sound, but I've found it has a fairly negative impact on Magento's overall performance.
  • Tweak MySQL Well of course, but the changes required are truly dependant on the load and the server specification.
  • Use tmpfs for var directory Don't bother, its a waste of RAM that could be better allocated elsewhere. If you're having to resort to this, then look into why your disk IO is so poor.
  • Increase the SHM Its a good idea, but test extensively and keep it sensible. Its also worth nothing, unless you state where to store cache data (SHM/Disk), this will have no advantage for you.
  • Disable openbase_dir Its a performance KILLER, expect RPS to drop by 100% with this enabled.
  • Move .htaccess contents to Apache conf Don't bother, not only does it make it hard to manage, but the overheads of .htacess files is tiny, infact not noticeable on any benchmark.
  • Clustering Adding more hardware will always make things faster - but is a poor solution for a weak configuration.
  • Enable Caching Of course you should, this will hamper performance by about 50% when off.
  • Remove home page elements This is design dependant and has nothing to do with overall performance.
  • Compressing CSS files However, if you have installed Fooman Speedster and correctly setup mod_deflate - you needn't bother with this overhead.
  • Enable gZip compression in .htaccess Again, if Apache deflate is setup right, you don't need to do this, but it won't hurt.
  • Increase realpath cache size The jury is out on this, we saw no appreciable difference.
  • Put .php files into cache A correctly setup server needn't need this.
  • Use Lightspeed / Lighttpd Its a non option for us, but testing has shown very similar overall performance, but memory usage is significantly lower.
  • Use flat catalog Expect to see good gains from this on large catalogues.

Starting at the basics, a fresh empty server (Quad Core / 4GB RAM / Raid SATA HDD). Apache, PHP and MySQL installed on a single server with the standard Debian Lenny packages. A default install of the latest Magento Demo Store with sample data, testing with:

ab -c 20 -t 100 https://demo.sonassi.com/

Stage 1) 7 RPS

After extensive testing of APC/xCache/Zend/TurckMMCache/eAccelerator - we found eAccelerator consistently outperform the alternatives. As to what settings for eAccelerator, this is platform dependant - so I'm not going to post figures. Adding in an opcode cache improved performance by 100%.

Stage 2) 14 RPS

Then, bundling Memcached into the install helped significantly, adding around 20% performance. Remember to add the lines to local.xml - otherwise you won't feel the benefit.

Stage 3) 18 RPS

Modified DB settings to allow increased workload

Stage 4) 19 RPS

Tweaked MPM settings in Apache to manage child spawning better and connection. Modified PHP conf and added optimisation.

Stage 5) 20 RPS

By this point, it was a respectable figure that most 'dedicated' Magento hosts could only achieve. So, the above is a, albeit very vague, foundation for you to build your Magento store. I'll be honest though, although we operate a dedicated MySQL network, running the MySQL server on the same server as the DB (as in the tests above) had VERY LITTLE overall impact on performance. It was in the region of 1 RPS on average - not really worth the expense to offload DB requests externally for most users.

As we want to be a specialist in Magento hosting, accepting 20 RPS was a non-option. I'm not going to go into any detail (otherwise we'll be giving away our game plan), so if you want seriously fast Magento hosting - try us out, you won't be disappointed.

After further customisation, again, only in the userspace, we brought our Magento performance into the big leagues. A sustainable average of 32 RPS. Testing a sustained load over a period of 1 hour with 100 concurrent users, our RPS fell to around 30 - showing our capacity meets our performance. Here's the output from ab.

Sonassi Media Services - https://demo.sonassi.com/

Concurrency Level:      20
Time taken for tests:   100.168 seconds
Complete requests:      3131
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      70223319 bytes
HTML transferred:       68968519 bytes
Requests per second:    31.71 [#/sec] (mean)
Time per request:       638.775 [ms] (mean)
Time per request:       31.939 [ms] (mean, across all concurrent requests)
Transfer rate:          685.77 [Kbytes/sec] received
Our new Magento hosting plan is available now.

You can even see how we compare to our rivals, from our recent benchmarking tests.

[syntaxhighlighter]