Magento Performance Print

Introduction

The basics — Making Magento run fast

Magento speed — the Big Five (what works)

• CPU: Choose a fast webhost
  Slow CPUs are the reason why cheap hosts run Magento so badly. Without fast CPUs, the store is going to be slow. CPUs can be compared on a benchmarking site to see how fast they are (at the time of writing M.D.G. IT uses Xeon E5-2680 v2). GHz values are not an indicator of absolute or relative speed — a 3 GHz processor from 2005 is going to be incomparably slower than a modern 2.6 GHz processor. The critical factors are:
  • having fast CPU cores
  • having access to cycles on those CPU cores. This is the problem with oversubscribed shared servers, for example, which are designed for lightweight applications like Wordpress: individual websites don't have access to enough CPU cycles to generate pages quickly enough. This is also an issue with AWS, where an instance's access to CPU cycles is restricted.
    
    
• Code: Don't slow down the site with bad extensions and bad development
  Magento, on a fast CPU, without any other optimisations, runs well. Tweaks can make it run faster, but never to the extent that bad code makes it run slower. The most significant factor in Magento speed problems after CPU speed is problems introduced by developers or extension installers during site customisation or updates. See our separate Development Guidelines article.
  
  
• Caches: Never disable caches on production
  If a store is in production, every cache must be green in the Magento backend (System — Cache Management). If a Rewards Points extension or a new menu block don’t work properly with the caches on, it is the extension that should go, not the caches. Magento is not designed to run in production (where multiple simultaneous requests are likely) without caching, and disabling any of caches in the backend is asking for trouble.
  
  
• Configuration: Run PHP and MySQL fast.
  This means mod_php (not suexec, no open_basedir.) or FastCGI, using APC (PHP 5.3), OPCache (PHP 5.4+) or another opcode cache, and setting up sane query cache and buffer pool sizes in MySQL. There are lists of 20+ other MySQL variables that are touted as improving Magento page load performance; however we have yet to find any measurable performance increases that these represent on fast hardware. In many cases suggested MySQL configuration values actually made sites run slower than previously.
  
  
• More caching: Move the load off Apache
  This isn't a substitute for the above (see more on Varnish below), however Varnish is the difference between a fast site and a site that runs as quickly as possible. See here for a Varnish demonstration site. Varnish caches as much as possible of each page when it is first loaded, only fetching personalised content (e.g. cart contents) from Apache. Likewise, a CDN caches images and other static content, and delivers these directly to visitors from remote servers.

What doesn't work

• Focusing on server settings as a response to problems caused by code
  No amount of caching or tweaking will return normal performance to a site that has significant development issues. Problems introduced in code need to be fixed there. The following is unfortunately a common pattern:
  
  • A client finds a developer, often offshore to reduce cost, who is likely to be inexperienced in Magento, whether or not they admit the fact. There are always exceptions, however good Magento developers are not likely to be looking for work on freelancing websites for $20 / hour. The problem is that while it's likely that the first Wordpress site a PHP developer builds is going to work well, it's even more likely that the first several sites a PHP developer builds in Magento are going to have significant problems. 
  • This developer typically works alone, without access to senior developers who can give advice about how to build in Magento to keep the site fast. No source control is used.
  • Speed is not tested and overall performance is not mentioned at all during the site build.
  • Speed issues become obvious shortly after going live, when the site can't handle moderate traffic, or when real products start to be created in the catalogue.
  • When faced with the tedious process of removing customisations one by one until the cause of the speed issues is identified, developers start suggesting PHP and MySQL configuration values, using Nginx, or using grossly overpowered servers, in the hope that these will restore normal performance

• Session store in database. The theory is that the database can cache this in RAM. The reality is that unless you have incredibly slow disk IO, the access time to store and retrieve cache information is irrelevant to most installations.

• Session store on TMPFS. As above, the idea being that all cache info is stored in RAM. Other than wasting RAM that can be better used elsewhere, this made no measurable difference in our tests. Writing and retrieving data to and from cache isn’t the problem - the problem is the CPU churning to generate the page / cache contents in the first place.
  
  
• MySQL configuration. The bottleneck in Magento page loads isn't database access, it's PHP. The two configuration options listed above do speed things up, but even these are single digit percentage increases on frontend pageloads (effects on indexing and other backend processes tend to be more significant)
  
  
• Nginx. Benchmarks comparing Nginx favourably to Apache are plentiful, however these invariably compare serving high volumes of static pages. It's not Apache causing a CPU core to run at 100% for 100ms while a Magento page is generated, but PHP. Nginx still needs to make a request to PHP FPM for the actual PHP to run. Our tests have shown quite conclusively that properly configured Apache / mod_php or PHP-FPM runs as fast as Nginx / PHP-FPM. 
  
  
• Considering images. The number and size of images on a site has no relation whatsoever to how long it takes to generate HTML. HTML loads first, the page then start rendering, and then images are loaded. If it takes too long for the page to start loading this is not because of image size. See here for testing HTML response times.
  
  
• Blaming catalogue size. Larger catalogues tend to highlight problems in code. While code problems can cause larger categories to load significantly slower than small ones, the problem is still in the code. We've tested catalogues up to 1 million SKUs on PowerBase VPSs, without any noticeable performance issues in the front end when using the default Magento theme, without extensions.
  
  
• Blaming the theme. There is no reason why a good looking, well designed theme should be any slower than the Magento default theme. If switching to a custom theme slows down the site, this is because the implementation of the theme has problems, not because a particular design would by its nature have performance implications.