14

In Magento EE 1.12.0.0 It would seem that no matter what configuration changes I make to app/etc/local.xml, the default file cache continues to be used (which is evidenced by var/cache/ always filling).

Expectation

  • Memcached is used as fast_backend.
  • Database is used as slow_backend.
  • File cache is not used at all (i.e. var/cache/ should always be empty).

Actual Output

  • Memcached is used as fast_backend.
  • Database is not used at all.
  • File cache is being used.

Testing Procedure

  1. Make configuration change to app/etc/local.xml.
  2. Restart Memcached and Apache (just for good measure and it's on my local dev box so I may as well).
  3. Clear the file cache (rm -rf var/cache/*).
  4. Refresh the home page.
  5. Check the contents of the file cache (ls var/cache).
  6. Become saddened and return to #1 with a different config change.

The Config

The contents of my app/etc/local.xml is as follows:

<config>
    <global>
        <install>
            <date><![CDATA[{{actual_data}}]]></date>
        </install>
        <crypt>
            <key><![CDATA[{{actual_data}}]]></key>
        </crypt>
        <disable_local_modules>false</disable_local_modules>
        <resources>
            <db>
                <table_prefix><![CDATA[]]></table_prefix>
            </db>
            <default_setup>
                <connection>
                    <host><![CDATA[{{actual_data}}]]></host>
                    <username><![CDATA[{{actual_data}}]]></username>
                    <password><![CDATA[{{actual_data}}]]></password>
                    <dbname><![CDATA[{{actual_data}}]]></dbname>
                    <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
                    <model><![CDATA[mysql4]]></model>
                    <type><![CDATA[pdo_mysql]]></type>
                    <pdoType><![CDATA[]]></pdoType>
                    <active>1</active>
                </connection>
            </default_setup>
        </resources>
        <session_save><![CDATA[db]]></session_save>
        <cache>memcached</cache>
        <slow_backend>database</slow_backend>
        <slow_backend_store_data>1</slow_backend_store_data>
        <memcached>
            <servers>
                <server>
                    <host><![CDATA[{{actual_data}}]]></host>
                    <port><![CDATA[{{actual_data}}]]></port>
                    <persistent><![CDATA[0]]></persistent>
                    <weight><![CDATA[2]]></weight>
                    <timeout><![CDATA[10]]></timeout>
                    <retry_interval><![CDATA[10]]></retry_interval>
                    <status><![CDATA[]]></status>
                </server>
            </servers>
            <compression><![CDATA[0]]></compression>
            <cache_dir><![CDATA[]]></cache_dir>
            <hashed_directory_level><![CDATA[]]></hashed_directory_level>
            <hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
            <file_name_prefix><![CDATA[]]></file_name_prefix>
        </memcached>
    </global>
    <admin>
        <routers>
            <adminhtml>
                <args>
                    <frontName><![CDATA[admin]]></frontName>
                </args>
            </adminhtml>
        </routers>
    </admin>
</config>
2
  • 1
    As an aside, required reading: Magento / Zend Framework's TwoLevels Cache Backend Mess
    – benmarks
    Commented Apr 7, 2015 at 19:07
  • I never did find a solution to this problem; however, as I have since worked on additional Magento projects under the employ of a different company and have used configurations similar to those described here, I am inclined to believe that it was an issue with one of: 1. That installation of Magento (bad modifications/modules/etc) 2. The company's provisioning scripts for their servers being poorly adapted from Drupal and some things were missed 3. Act of God/Nature 4. (most likely) It's Magento Regardless, @fantasticrice gave a great answer that should help Googlers, so he gets the prize!
    – Robr3rd
    Commented Nov 4, 2015 at 21:44

1 Answer 1

5

I think that is not the right format for the cache nodes. My understanding is that all the cache settings should be nested inside the <cache> node. So to use two-level cache with memcached + database it would be something like this:

<cache>
    <backend>memcached</backend>
    <slow_backend>database</slow_backend>
    <memcached>
        <servers>
            <server1>
                <host>...</host>
                <port>11211</port>
                <persistent>1</persistent>
                <weight>2</weight>
                <timeout>10</timeout>
                <retry_interval>10</retry_interval>
                <status/>
            </server1>
            ...
        </servers>
        <compression>0</compression>
        <cache_dir/>
        <hashed_directory_level/>
        <hashed_directory_umask/>
        <file_name_prefix/>
    </memcached>
</cache>

Bear in mind that <full_page_cache> can be configured exactly the same way and can use different settings if you wish. They are just two separate cache instances.

Just as a side note, I would highly recommend using Redis instead. It supports tags, so it can be used as a single level cache and it will perform much better than two-level memcached + database.

5
  • 3
    I second the advocacy for Redis. The db slow backend causes more harm than it does help.
    – philwinkle
    Commented Apr 7, 2015 at 18:01
  • I have also tried that configuration (it's actually what I started with -- the one I posted was suggested as an alternative since the above wasn't working). Would the <full_page_cache> possibly be filling var/cache? It's my understanding that it instead uses var/full_page_cache. I have also tried using the same <cache>...</cache> (your style) for <full_page_cache> and in enterprise.xml to no avail. As far as Redis goes, unfortunately using the DB backend is the requirement.
    – Robr3rd
    Commented Apr 7, 2015 at 21:32
  • I just noticed that you have <cache>...<servers>...<server1>...</server1>. Is the 1 in server1 important?
    – Robr3rd
    Commented Apr 7, 2015 at 21:33
  • @RobertRobinson - nope, not important at all except as a way to define multiple nodes under <servers>. You could use foo, bar, baz just as easily as server1, server2, server3. You are correct that full_page_cache instance gets its own subdirectory under var if it is using files. Commented Apr 7, 2015 at 21:41
  • @RobertRobinson - you might be interested in this extension to see the status of Magento’s config. Commented Apr 7, 2015 at 22:06

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.