Your Memcache configuration in
./app/etc/local/xml will dictate what Memcache is actually caching.
If you are only using a the single-level cache (without
<slow_backend>), then Magento will store its cache (in its entirety) in Memcache.
**HOWEVER** without the
<slow_backend> defined – it is caching content, without cache_tags – ie. without the ability to differentiate cache items.
Eg. configuration, block, layouts, translations etc.
So, without the
<slow_backend> defined, you cannot refresh caches individually, in-fact, you’ll almost always have to rely on “Flush Cache Storage” to actually see updates take effect.
To verify Memcache is being used, just empty the contents of
./var/cache/ and verify that it remains empty – even after browsing a few pages.
Using the slow backend
So, the solution to have caches that can actually be refreshed individually and permit updates without the requirement to flush the entire cache is to use the slow backend.
Using the DB for this means that it can store the cache tags and allows individual caches to be refreshed. However, this in itself creates its own issue.
Due to the cyclic nature of Memcache, it will self truncate when it is full. But the DB cache tags (core_cache_tag) will continue to grow and grow and grow. Without monitoring, it will become a multi-million row table that locks up the entire store for even the most simple operation (product save, order save, order create).
So what is the solution
You have a few options:
- Use the one level cache with Memcache – but accept the failings and resort to entire cache purges for minor updates to be reflected
- Use the two level cache with Memcache and DB – but put up with the increased DB load/size and have to manually truncate the table to keep it under control (or resort to this)
- Use files for cache storage – but accept the complete lack of speed and the bug that the cache tagging can also break and cause thousands of the same files to be created in
- Use DB for the entire cache – see this
- Or try Redis