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 http://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, http://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).
This will speed up the users experience, but actually causes unintelligent benchmarks (like Siege and AB) to give worse results.
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.
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.
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.
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.
Adding more hardware will always make things faster – but is a poor solution for a weak configuration.
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 http://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 – http://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.