Tag Archives: cache

May 21

  • Created: May 21, 2011 10:28 AM

Clearing the Cache in Magento

Clearing the Cache in Magento
“What is the difference between the “Flush Magento Cache” and “Flush Cache Storage” buttons?”
Flush Magento Cache and Flush Cache Storage

We get this question often enough that it’s worth making a short blog post about it. In order to understand the difference between these two options, it’s important to know a little about how caching works in Magento. Specifically the concepts of ids and tagging.

Essentially, an “id” in terms of caching is simply a unique string used to identify cache records in a shared storage. A cache “tag”, is another string that’s used to classify different types of data your application is caching. In Magento, tags differentiate between the following Cache types:

  • Configuration (non-layout XML files)
  • Layouts (all those XML files under app/design/…)
  • Blocks HTML output (Page blocks like headers, footers and callouts)
  • Translations
  • Collections Data
  • EAV types and attributes (reduces some database lookups)
  • Web Services Configuration

Let’s take a look at a list of cache files from a default Magento store for an illustration: Read more

Mar 25

  • Created: Mar 25, 2011 12:00 PM

Optimizing APC Cache Settings for Magento

Optimizing APC Cache Settings for Magento
APC (Alternative PHP Cache) is an opcode cache for PHP that works very well to speed up page loads when used on servers running Magento. There are many opcode caches available (APC, accelerator, xcache, etc) which can be used with Magento, but we will be focusing on APC here as it along with eAccelerator are recommended by Magento in their performance whitepapers. eAccelerator also works very well with Magento, but please note that you must use version 0.9.5 or older.

APC can be used for two purposes within Magento. The first is as an opcode cache that PHP will utilize to cache any PHP files that are compiled through it. APC can also be utilized by Magento as an fast backend cache for Magento data. This can be configured within the Magento local.xml. Read more

Oct 16

  • Created: Oct 16, 2010 10:05 PM

Increase WordPress performance with WPSuperCache

WordPress
Last week, we covered speeding up WordPress with Memcache, which was simple enough, but most shared hosting plans don’t allow you to run memcached. Even if you are allowed to run the memcache daemon on your server and you have the WordPress memcache plugin installed, configured, and working properly, you’re still serving dynamic pages, and every visitor equals at least one MySQL database query.

The solution, or second half to the solution if you’re already using memcache in WordPress, is to use “static page caching”, which is an “old trick” that webmasters have been using for many years. What is newer, however, is the automatic generation / purging (called “garbage collection”) of cached objects that WPSuperCache can provide your site with.

Normally, and this is just an overview, the following happens when a user visits your WordPress site:

  1. Apache uses mod_rewrite to check the .htaccess file to see if the user should be redirected or if any URL transformations should be applied (“rewrites”).
  2. Apache sees that index.php needs to be processed by PHP because of the configured MIME type.
  3. Apache tells PHP to process index.php based upon the requested URL and any .htaccess transformations (“rewrites”).
  4. PHP loads and parses index.php (the WordPress software) and loads any additional files specified. These are sometimes called “includes”.
  5. PHP runs any necessary MySQL queries specified in the PHP files, and returns the results back to PHP for more processing.
  6. PHP generates the final page and hands it back to Apache.
  7. Apache sends the generated (“dynamic”) page back to the requesting user.

Again, this is a simplified version of what is actually happening. For more details on the exact process, if you’re interested, check out: http://codex.wordpress.org/Query_Overview

While the above process works well enough for a decently-sized site, there is still a lot of steps and a lot of work that the server has to do to generate the page. Add any overhead incurred by plugins, statistics tracking, comments, and ads, and you can see how sites that are reasonably quick with a few visitors can slow down dramatically when they receive serious traffic.

WPSuperCache aims to remedy this by generating the dynamic pages only once, then storing the page for the next visitor who requests it. The second visitor to the page gets a “static” page, which is much easier on the server, since it just has to send the data instead of doing any processing via PHP.

The diagram below provides an overview of this functionality:

Nexcess-WPCache

As you can see, this can be much more efficient. For more details on how WPSuperCache actually works, you can check out the developer’s page at http://ocaoimh.ie/wp-super-cache/

WPSuperCache can be installed directly from WordPress by going to Administration -> Plugins -> Add New, then searching for ‘WPSuperCache’ and clicking “Install”. WordPress should take care of the rest of the installation.

Now we’ll need to configure WPSuperCache to actually cache our pages. A link to the WPSuperCache plugin configuration page should appear in a red box at the top of your page, but it if doesn’t, just go to Settings -> WP Super Cache in your WordPress admin menu on the left side of the page.

Here are the options that we typically recommend for all users:

  • Cache hits to this website for quick access. (Recommended)
  • Use mod_rewrite to serve cache files. (Recommended)
  • 304 Not Modified browser caching. Indicate when a page has not been modified since last requested. (Recommended)
  • Cache rebuild. Serve a supercache file to anonymous users while a new file is being generated. (Recommended)
  • Clear all cache files when a post or page is published

Now click the blue “Update Status” button at the bottom of the top section, under the settings you just changed. You should now see a message at the top of your page, something like “Rewrite rules must be updated”. Scroll down the page until you get to the “Mod Rewrite Rules” section. Find the blue button that says “Update Mod Rewrite Rules” and click it. The “Mod Rewrite Rules” section should now have a green background, indicating that the rewrite rules in your .htaccess file are correctly configured.

To test the cache, log out of your WordPress administration panel and visit your site. View the source of the page (ctrl+u in some browsers) and scroll down to the very bottom. You should see something like this:

&lt;!-- Dynamic page generated in 0.208 seconds. --&gt;<br />
&lt;!-- Cached page generated by WP-Super-Cache on 2010-10-16 19:13:06 --&gt;<br />
&lt;!-- super cache --&gt;

If you don’t see an HTML comment from WPSuperCache similar to the above, try holding down the “shift” key on your keyboard and click your browser’s refresh button to “hard refresh” the page. If that still doesn’t work, try clearing your browser’s cache, restart your browser, and try again. Note that the timestamp in the HTML comment is the time that the page was cached at, so you can tell when the page was generated by WPSuperCache.