MySQL and Magento Peformance Tuning

Define performance Do you mean the page load time for a single user, or the overall capacity/total concurrency? The two are very distinctly different – and not strictly related. It is entirely possible to have a fast store with limited capacity; or a slow store with lots of capacity. So when addressing either type of performance: Single user perceived page load time Total capacity/concurrency You have to tackle each independently with their own solutions – especially since each have their own bottlenecks. Lets make the assumption you are with a competent host that has already configured the server optimally for your store. Single user perceived page load time Is MySQL the bottleneckNo. Not directly. Its all about latency, in the majority of cases when testing page load time – only the caches will be hit. So the key here is to minimise latency. Tune MySQL cache sizes appropriately (there is … Continue reading

Magento with Varnish

Is Varnish right for you? Varnish isn’t the be-all and end-all of Magento performance. Its great to offset load from bots & window-shoppers – but it shouldn’t be your first port of call to actually making your store faster. In fact, implementing Varnish should be the last performance modification to your store. Only drop it in once you are seeing the page load times Magento is capable of delivering without it (Eg. <600ms page load times). Your store still needs to be fast As Varnish still requires at least a single page load to prime the cache, it means your un-cached performance still needs to be very good. A vast majority of unique URLs (layered navigation hits, search queries etc.) will never really end up being served from Varnish unless either: a) Your TTLs are so high, that a search query from 4 days ago is still valid today b) … Continue reading

Magento MySQL Optimisation

We’ve got a fairly vast experience of MySQL clusters – and Percona have worked with us on a number of occasions when pushing the boundaries of complex configurations. Can Magento natively handle read-only slaves Magento is natively capable of splitting off reads/writes to different database servers (with the exception of a few broken releases, eg. EE 1.11) – allowing you to offset select load to an additional (or more) server(s); and forwarding all the update/write queries to a single master. When should I do it This is a more appropriate question. With dedicated Magento operating systems like MageStack – it is becoming more common for in-built server side advanced caching techniques to be available and easily used (such as Varnish front end caching and Redis back end caching). Historically, Magento has never been bound by MySQL – but rather PHP. But as Varnish and Full Page Caching (FPC) are used … Continue reading

Why Siege isn’t an accurate test tool for Magento performance

We’re getting pretty concerned at Sonassi HQ with the growing confusion surrounding transactions per second (TPS), requests per second (RPS) and concurrency by the community as a whole. Shamefully, I fear that we are guilty for bucking this trend. We created a monster, now its time to put it down 3 years ago, when we really started to get engaged in web hosting, we launched a little project called Mage Benchmark. The purpose was to have a portal where specialist Magento web hosts could put a brief description about themselves and volunteer a URL for a self-hosted demo store – that could be externally tested to give a viewpoint of uptime, page load time and concurrency support. This attracted both acclaim and sadly, criticism, amongst the community. Early on, before Mage Benchmark, Sonassi and Pro Contractors (two high performance, specialist Magento web hosts) had spurred a trend of performance testing … Continue reading

Why shouldn’t I use Nginx for Magento

We are going to give you a loose analogy – a (Magento) fast-food restaurant. The cast The customer (at the drive-through), is the customer on your web store. The till operator (who sits on a chair and hands you the bag of food through the window – Web Server) The chef (who cooks the meals – PHP) The su-chef (who prepares the ingredients for the meals – server subsystem) The Challenge The average meal takes 2 minutes to prepare, 12 minutes to cook and 5 seconds to hand to the customer. Now, lets take the perception of Apache (an overweight, unfit, slow window attendant), the kitchen takes 14 minutes to make the meal, hands it to him – then he passes it to you. He is only passing 1 bag, every 14 minutes, a pretty easy job. So lets improve performance We want the business to run faster – so … Continue reading