Published: February 6, 2017

When Magento saves data to cache, it has the option to add “tags” to the data it is saving. This feature, which is built into Zend Framework 1, is particularly useful as it allows the application easily invalidate all data associated with a particular tag.

For example, when the name of a product changes, all pages on which that product was displayed can be invalidated by passing the appropriate tag to the cache instance’s clean method. If the product with entity_id 1 had changed, cleaning all cache data would look like this…


One tag that Magento’s Enterprise_PageCache module makes uses of is the REQUEST_PATH tag. In this post, we’ll first explore how Magento uses this tag out-of-box. Then, we’ll take a look at how we can take advantage of this tag.

Mage::getStoreConfig() in tight loops

Published: February 2, 2017

Recently, while doing some profiling of an uncached category page, I noticed something funny…A sizable amount of time being spent on Mage::getStoreConfig().

Digging in, I saw that it was coming from the navigation module. It contained a function called getAllFilterableOptionsAsHash, which builds a map of URL keys (using it’s own logic) to Magento attribute option IDs. It looks something like this (abbreviated for simplicity’s sake)…

public function getAllFilterableOptionsAsHash()
    $hash = array();

    $attributes = $this->getFilterableAttributes();

    $options = $this->getAllOptions();

    foreach ($attributes as $a) {
        $hash[$a->getAttributeCode()] = array();
        foreach ($options as $o){
            if (o['attribute_id'] == $a->getId()) {
                $key = $this->createKey($o['url_alias']);
                $key .= Mage::getStoreConfig('module/part/special_char');
                $hash[$code][$key] = $o['option_id'];

    return $hash;

In this case getAllFilterableAttributes will return all attributes that are filterable and getAllOptions will return all options for filterable attributes. On the site in question there were 18 filterable attributes with ~4250 options.

Based on the code above, this means Mage::getStoreConfig('module/part/special_char'); will be called ~4250 times. I began to wonder what the benefit might be of caching the value in an temporary value, rather than calling Mage::getStoreConfig over and over. Here, I’ll share the results of my investigation…

How Partial Reindexing Schedule Impacts Page Cache Hit Rate

Published: January 30, 2017

One factor that impacts your Magento site’s full page cache hit rate is your partial reindexing schedule. By partial reindexing, I mean execution of the enterprise_refresh_index job, which runs when the Magento cron is executed in “always” mode.

Let’s take a closer look at the interplay between partial reindexing and full page cache hit rate.

HTTP Response Header Size Limits

Published: January 24, 2017

A while back I published a post about HTTP request header size limits. At the time, I had just finished remediating an issue where requests were being blocked by a WAF for exceeding the “max header size” policy.

Recently, I’ve been dealing with a similar, but slightly different issue…requests failing due to the size of the response headers. Here, I’ll document my findings on this issue…

MySQL Query Cache Hit Rate

Published: January 22, 2017

MySQL’s query cache is a useful tool to improve performance and scalability. However, if not implemented correctly, it can do more harm than good…

The query cache offers the potential for substantial performance improvement, but do not assume that it will do so under all circumstances. With some query cache configurations or server workloads, you might actually see a performance decrease.

One critical data point to look at when measuring the effectiveness of query caching is the query cache hit rate. Let’s take a look at how to do that.

Enterprise_PageCache is Borked In 1.14.3.X

Published: January 20, 2017


If you are thinking about installing or upgrading to Magento Enterprise 1.14.3.X read this post right now. Enterprise_PageCache is completely borked in both and The repro steps for the bug are not only dead simple, but also extremely common user behavior…

Steps To Reproduce

  1. Ensure that full page cache is turned on
  2. Navigate to a category page
  3. Apply any layered navigation filter
  4. Remove the filter you just applied

Expected result

Unfiltered category page is displayed

Actual result

Filtered category page continues to display

What’s worse, the cache for the unfiltered category page is now poisoned for any user who visits that page!

The good news it that there’s a patch available, SUPEE-9465. If that’s all you’re looking for I’ve posted it here.

However, because it’s interesting, let’s take at what went wrong starting in