Correct Method of Flushing Caches & Managing the Compiler
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
websiteroot/var/cache
and manually deleting all of the files. Same goes for
websiteroot/var/full_page__cache
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
websiteroot/app/code/core/Enterprise/PageCache/etc/cache.xml
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()
{
$this->_collectFiles();
$this->_compileFiles();
$this->registerIncludePath();
return $this;
}
Kicked off by the $this->_collectFiles(); call, Magento copies all PHP files from both the
app/code
and lib directories to the
/includes/src
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
app/code/core/Mage/Catalog/Model/Category.php
but, with compilation enabled, has now become
includes/src/Mage_Catalog_Model_Category.php
/**
* 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');
$this->_mkdir($destDir);
foreach ($paths as $path) {
$this->_controllerFolders = array();
$this->_copy($path, $destDir); // this one will run recursively through all directories
$this->_copyControllers($path);
if ($path == $libDir) {
$this->_copyAll($libDir, $destDir);
}
}
$destDir.= DS.'Data';
$this->_mkdir($destDir);
$this->_copyZendLocaleData($destDir);
return $this;
}
Controllers are getting an other treatment. All controller directories are copied to
includes/src/
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.
> #define('COMPILER_INCLUDE_PATH', dirname(__FILE__).DIRECTORY_SEPARATOR.'src');
> #define('COMPILER_COLLECT_PATH', dirname(__FILE__).DIRECTORY_SEPARATOR.'stat');
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));
Mage::dispatchEvent(
'controller_action_predispatch_'.$this->getRequest()->getRouteName(),
array('controller_action'=>$this)
);
Varien_Autoload::registerScope($this->getRequest()->getRouteName()); // right here
Mage::dispatchEvent(
'controller_action_predispatch_'.$this->getFullActionName(),
array('controller_action'=>$this)
);
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
app/Mage.php
if (defined('COMPILER_INCLUDE_PATH')) {
$appPath = 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.
COMPILER
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:
- is it safe to run magento compiler?
CACHES
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.
NOTE
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:
- https://stackoverflow.com/questions/5955365/what-is-the-difference-between-flush-magento-cache-and-flush-cache-storage-i