Magento 1.9 Performance Checklist

Magento 1.9 is still an active and widely adopted E-commerce solution, but it is still a large framework with many files. If installed on a misconfigured server, Magento 1.9 performance can lead to a store that your customer will leave immediately.

Let’s review the best practices and software required to run Magento 1.9 with excellent performance.

1. Use caching plugin

Lesti FPC and Turpentine are the most prominent freeware solutions. Be sure you know how Turpentine is bad, if you want to go with that route.

Your Magento theme has to be fixed if it has incompatibilities with FPC. One incompatibility example would be:

<?php if ($this->getChildHtml('global_messages')) { ?>

And it must be changed to:

<?php if (Mage::getSingleton('core/session')->getMessages()->count()) { ?>

1.a. PotatoCommerce FPC

Our recommendation is with Potatocommerce Full Page Cache, official GTMetrix partner.

Note that, as with any other cache, this FPC plugin is vulnerable to increased cache size because of bad bots requests. This is not cache poisoning because the bad cache is not used, but the issue will cause your cache to grow and bad requests will consume cache size.

1.b. Lesti FPC

Lesti FPC is easy to install and configure. It allows you to store its cache to Redis.

1.c. Turpentine

This caching plugin stands superior to other full page cache plugins. It works coupled with the Varnish caching server. If you’re looking into serving dozens of customers at the same moment, you might want to give Varnish a go.

However, Turpentine has a major flaw – it is not a real full page cache. It works as an FPC only in old Magento versions. Read more about why Turpentine is not FPC.

2. Clean up Magento database. Reduce your database size

Magento database size will always affect store’s performance. If your Magento database is huge, make sure it doesn’t contain useless data and optimize its size.

3. WDSL cache

Ensure the WDSL cache is enabled. This is especially useful in case you have a use of Magento Core API.
Go to System > Configuration > Services > Magento Core API.
Select ‘yes’ to Enable WSDL Cache.

4. Speed up your search

By default Magento search is slow. No need to worry, as you can leverage open-source Sphinx search engine which will not only index your products and provide very accurate results. It will also increase the speed of searches a lot! We recommend Magento 1 Sphinx Search for implementing Sphinx support in your Magento 1.

5. Use Redis

Redis is a powerful software for storing data in memory. If you expect to serve many customers in your store with load balancing setup, Redis will come in handy for centralized cache storage.

Using Magento 2? Have a look at Magento 2 Performance Checklist

6. Dynamic ETags

You can save bandwidth and improve performance by adding conditional GET feature to your NGINX.

7. Solve deadlocks

Make sure that indexing does not lock your database tables. This is an important one. Apply patch for this, more details here

8. Solve deadlocks again

[mysqld] 
transaction-isolation = READ-COMMITTED

READ-COMMITTED reduces database table locks and is suitable for Magento workloads (requires citing).

9. Avoid PHP session garbage collector.

Use a cron job for cleaning up PHP sessions.
See this issue

Cleanup sessions like a PRO

10. Clean up unused media

Over time, the media file directory can grow huge. To clean it up, use EAVCleaner:

n98-magerun eav:media:remove-unused

Furthermore, the image cache (thumbnails), grows over time with unused image’s thumbnails. Do image cache clearing around once in 1 year:

n98-magerun media:cache:image:clear
# flush cache especially FPC, so that Magento can dynamically recreate thumbnails upon access
n98-magerun cache:flush

11. Use the async index plugin by Mirasvit

Since it can run with its own job, indexing won’t delay cron executions for standard Magento tasks.

12. Eliminate cache clearing plugins or modules

There are many modules, custom code, etc. continuously implanted by developers to unnecessarily clear caches.
They typically serve one purpose, to fix their own flaw in writing a code that does not interact with the Magento database correctly.
In other words, not using Magento framework classes and methods for updating data.

This results in an “invalidated” cache message in the Magento admin area.

Here’s an expanded answer and an actual solution to this.
Some developers are even proudly presenting their cache-clearing solutions without the shame of the actual consequences (see the other answers on that link).

Search, investigate and remove any custom code using this ->cleanType:

A disgusting example found on a live website: app/code/community/Loewenstark/InvalidCache:

<?php

class Loewenstark_InvalidCache_Model_Observer
{
    /**
     * Remove the annoying notification on product save.
     * @see https://gist.github.com/1074482
     *
     * @param Varien_Event_Observer $observer
     */
    public function clearBlockCache(Varien_Event_Observer $observer)
    {
        Mage::app()->getCacheInstance()->cleanType('block_html');
        Mage::app()->getCacheInstance()->cleanType('fpc'); // for magento enterprise
        return $this;
    }

    /**
     * Clean Up Cache via CronJob
     *
     * @return void
     */
    public function clearInvalidCache()
    {
        // get all Cache Types
        $types = Mage::app()->getCacheInstance()->getInvalidatedTypes();
        if(count($types)>0){
            foreach($types as $_type)
            {
                // clear invalid caches
                if($_type->getId()=="fpc")
                    continue;
                Mage::app()->getCacheInstance()->cleanType($_type->getId());
                Mage::Log(sprintf("Cleared Cache: %s",$_type->getId()),null);
            }
            //finally clear FPC
            Mage::app()->getCacheInstance()->cleanType('fpc');
        }
        return $this;
    }
}

Stupidity is never ending. How do people propose solutions to others without fully understanding how the system works?

To recap this item, the proper solution is only one: removing bad code that does things like plain SQL queries or writing to .phtml files.

13. Monitor your cache usage and size it appropriately

Investigate the current size of your Redis-stored full-page cache. You may want to run it in a separate Redis instance, then check memory usage.

Find the currently configured cache max size:

redis-cli -s /var/run/redis-fpc/redis-fpc.sock info | grep maxmemory_human

Find currently used cache size:

redis-cli -s /var/run/redis-fpc/redis-fpc.sock info | grep used_memory_human

Then size the maxmemory in redis-fpc.conf appropriately higher if available RAM allows, and if the current usage is near to the current maxmemory.

14. Do not clear cache often

Rebuilding the cache on a large website might take days and should be avoided. Choose a deployment day when you need developer changes to be deployed and clear cache only then.

Sometimes developers implant cache clearing crons and modules like in the previous points. Make sure those are not placed on your website.

It is also important to patch the cache corruption bug.