I'd like to know if there's any prefered procedure for the following:

  1. Flushing of the Magento cache
  2. Enabling/Disabling of the Magento Compiler

1. Flushing of the Magento Cache

There are a few options here, namely:

  • Checking the line items and submitting refresh from the Actions dropdown box
  • Clicking the Flush Magento Cache button, and
  • Clicking the Flush Storage Cache button

Is there any prefered order in which to do these? What is the difference between the Magento cache & the Storage cache?

2. Enabling/Disabling of the Magento Compiler

a) Enabling the Compiler

When it comes to enabling the Magento compiler, should one have all the store caches enabled? Or should you only activate the caches after enabling the compiler & running the compilation process? Once you've enabled the compiler should you refresh all caches? And if so, does that include Flushing the Magento cache & storage cache (as mentioned above)

b) Disabling the Compiler

When it comes to disabling the Magento compiler, should you disable all the caches first, and then re-enable them after it has been disabled?

Is there any difference between leaving the caches on and disabling / enabling the compiler? What performance impact does it cause?

Any input would be much appreciated

  • Its easy to remember. Don't flush the cache on a production store. Don't enable the cache on a development store. Commented May 20, 2014 at 21:02
  • 1
    And if flushing cache on your production store causes the site to crash, you didn't do enough testing on your staging server and some bad code got through, hence the "Don't enable the cache on a development store." Flushing cache shouldn't ever cause Magento to crash. CBR error (Commit before ready) Commented May 26, 2015 at 17:14

4 Answers 4


Flush Magento Cache - This clears the cache (var/cache) of any items that Magento knows it has created.

Flush Cache Storage - Clears everything in var/cache, regardless of how those files in there were created.

So, if you want to be safe you're clearing everything, you may choose "Flush Cache Storage" which will essentially clear out var/cache.

For the compiler, I would recommend flushing the Magento cache after enabling compilation and running the compilation process. This ensures that the cache is cleared of any non-compiled data.

When disabling compilation, I would disable it first, then flush the Magento cache afterwards. This again ensures the cache is clear of any compiled data.

Unless you are testing things a lot, I would always recommend leaving the caches on. Compilation can be hit or miss in terms of performance. I've seen it make things faster, and many times seen compilation make things slower and cause issues with 3rd party extensions. I'd recommend getting a baseline for a category page load time (using Firebug / developer tools) with compilation off, then again with compilation on, and see if there is a large difference.

You'd likely be better off using things like an opcode cache in PHP, proper MySQL query caching, combining css/js files, using gzip compression, using a Full Page Cache extension, and proper settings for browser caching of files.


Magento cache is no different. Starting off with the basics, cache options can be viewed by navigating to

System->Cache Management

in the backend. You can see the different areas of caching that can be enabled/disabled, such as any configurations, layout.xml, blocks, full page, and api files. Obviously the ideal is to have all of these enabled once the site is live.

The cache can also be cleared, or flushed, from here. Pressing the button labeled “Flush Magento Cache” will flush any cache files that match a certain set of built in default tags that Magento uses. This is the “safer” way to clear the cache, as it does not clear absolutely everything. If you are using any secondary cache types, then clicking “Flush Cache Storage” will ensure you have cleared you cache, as it clears EVERYTHING. The other two buttons you see on the admin page will clear the javascript and css, and catalog images.

An alternate, and slightly less safe way to clear the cache is by navigating to


and manually deleting all of the files. Same goes for


if you have full page cache enabled.

Full page cache, available on the Enterprise Edition, speeds your site up 10 fold, but its important to know a little bit about it, just in case you notice any dynamic content being cached. An interesting file to look at is


Here you can see what is being cached by FPC, the block name, the container name, and the session lifetime. If you find it absolutely necessary to edit or remove any of these blocks from the cache, you can do so by creating a module dependent on the PageCache module, and placing any modifications in there.

The placeholder tag tells the FPC that that block is considered dynamic. When a page is loaded, if the block is not yet in cache this ID value in the placeholder tags is searched for in the cache, and if it doesn’t exist, than that block is called and generated, and the ID is added to the cache.

Magento’s compilation feature can be found under

System > Tools > Compilation

If you are running a fresh install you probably get a system messages that both the includes and includes/src/ directories must be made writable. When this is done we can hit the ‘Run Compilation process’ button and you’re basically done, the Magento core is using compilation.

When Magento compiles it’s source code, the framework does a few things. Being either triggered via the admin or shell, see shell/compiler.php, all of the compiling is done by a single class: Mage_Compiler_Model_Process. Within this class you will find the following snippet which is actually a birds-eye view of the whole process.

     * Run compilation process
     * @return Mage_Compiler_Model_Process
    public function run()
        return $this;

Kicked off by the $this->_collectFiles(); call, Magento copies all PHP files from both the


and lib directories to the


directory. As you can see in the snippet below: during this process Magento recursively iterates through all files and directories. These paths are eventually used as the filename. When the recursive process hits a file it will check for a PHP extension and, when found, the file is copied to the compiler directory. Other file types are kept untouched.

As an example: the path for the class Mage_Catalog_Model_Category was


but, with compilation enabled, has now become


     * Copy files from all include directories to one.
     * Lib files and controllers files will be copied as is
     * @return Mage_Compiler_Model_Process
    protected function _collectFiles()
        $paths  = $this->_getIncludePaths();
        $paths  = array_reverse($paths);
        $destDir= $this->_includeDir;
        $libDir = Mage::getBaseDir('lib');

        foreach ($paths as $path) {
            $this->_controllerFolders = array();
            $this->_copy($path, $destDir); // this one will run recursively through all directories
            if ($path == $libDir) {
                $this->_copyAll($libDir, $destDir);

        $destDir.= DS.'Data';
        return $this;

Controllers are getting an other treatment. All controller directories are copied to


but are stored within a directory which has the name of it’s related namespace, think: Mage, Enterprise or your own given namespace.

Within these namespace directories the controllers are stored per module and the controller directory structure is kept untouched. The same goes for the filename, it’s just an exact copy. All this logic can be found in the following method $this->_copyControllers($path);

This second level of compilation collects all the scopes and their respective class lists from the admin. All these scopes are being processed by fetching the content of the related class files and write them into a single file named after the given scope.

     * Compile classes code to files
     * @return Mage_Compiler_Model_Process
    protected function _compileFiles()
        $classesInfo = $this->getCompileClassList();

        foreach ($classesInfo as $code => $classes) {
            $classesSorce = $this->_getClassesSourceCode($classes, $code);
            file_put_contents($this->_includeDir.DS.Varien_Autoload::SCOPE_FILE_PREFIX.$code.'.php', $classesSorce);

        return $this;

By default Magento creates four different scope files:

__default.php, __catalog.php, __checkout.php and __cms.php

During the process of building these scope files Magento automatically parses all class extends and interfaces that are being used by the classes provided in the scope list.

With all the files in place and compiled, Magento is ready to enable the compilation feature for usage.

Last but not least the configuration related to compilation is adjusted. This file can be found at includes/config.php and holds the following two constants. Upon enabling compilation the line regarding COMPILER_INCLUDE_PATH is uncommented and thus ready for action.


The code that is responsible for adjusting the configuration file can be found in the registerIncludePath method of the Mage_Compiler_Model_Process class.

During the bootstrap the compilation configuration file is included within the index.php file (around line 44). This makes the include_path constants available throughout the whole framework. The collect_path is something you can only enable manually to get more statistic information about the usage of your compiled files. This should not be enabled on live.

 * Compilation includes configuration file
$compilerConfig = 'includes/config.php';
if (file_exists($compilerConfig)) {
    include $compilerConfig;

From this point on Magento will check whether compilation mode is enabled with the following statement. Going through the codebase (using ‘grep’) you will notice that most of this logic can be found in the lib/Varien/Autoload.php file.

if (defined('COMPILER_COLLECT_PATH')) {
            // do stuff

The other place to look for is the Mage_Core_Controller_Varien_Action. In this class you will find the preDispatch() method, which is triggered for each controller action method before the method is actually dispatched. In this part of the source Magento’s autoloader class Varien_Autoload is being called upon to load a specific compilation scope file.

 Mage::dispatchEvent('controller_action_predispatch', array('controller_action'=>$this));
        Varien_Autoload::registerScope($this->getRequest()->getRouteName()); // right here

When running in compilation mode Magento only has a single include path, the includes/src/ directory, so each file is found directly at the first try. With the considerable amount of files that Magento has, this saves quite some time. The underneath snippet is taken from the


if (defined('COMPILER_INCLUDE_PATH')) {
    set_include_path($appPath . PS . Mage::registry('original_include_path'));
    include_once "Mage_Core_functions.php";
    include_once "Varien_Autoload.php";
} else {
     * Set include path
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'local';
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'community';
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'core';
    $paths[] = BP . DS . 'lib';

    $appPath = implode(PS, $paths);
    set_include_path($appPath . PS . Mage::registry('original_include_path'));
    include_once "Mage/Core/functions.php";
    include_once "Varien/Autoload.php";

When PHP includes a file, the content is compiled to opcode. This is a process that needs to be done each time a file is included. To improve the performance of your shop even further you can install APC on your server. APC caches the opcoded versions of the files, making them available for subsequent requests. So upon the next request: the file will be read from the APC cache, instead of having to go through the same process again and draining your performance.



All compiler files can be found in includes/ Just don't wipe .htaccess or config.php. If you view config.php You'll notice all enabling/disabling compiler does is removing the comments # before the two define. It's safe to assume a simple rm -Rf includes/src;rm -Rf includes/stat from the Magento root will wipe the compiled data.

Also consider using AOE_ClassPathCache along with APC, as this will be by far enough to remove the compiler out of the equation.

Also for more discussion on the topic:


This is purely defined on what caching backends you are using via your local.xml. If you are using the default files cache handler, then wiping var/cache and if Enterprise var/full_page_cache. If you are using a datastore such as Memcache, you'll need to either do this via Magento's Flush Cache Storage or via a means the cache datastore has to clear/wipe its cache.

Also more details on the possible data stores, Magento uses Zend_Cache for its Caching mechanisms. Which you'll notice relate to the local.xml cache Xpaths.


If you are running Enterprise, you'll find a second configuration file etc/enterprise.xml is where the datastore for the FPC is defined.

Whats the difference between Flush Cache, and Flush Cache Storage:


A very important note about the Magento Compiler. You need to turn off things like APC when doing compilation as the compiler can not compile what is in APC and will corrupt your compilation. For me that would mean unloading APC at the server and then restart Apache (httpd).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.