3

Why would the {% cache %} tag be storing a new cache every time the page loads (instead of just loading the existing cache)?

Unless I'm misunderstanding how caching works, the system should never record duplicate cache keys, correct?

enter image description here

Despite the data apparently getting cached, the page never feels like it's pulling from cache. Every page load feels long and sluggish.


UPDATE:

I've done some additional testing, and was able to get the caching to perform as expected. Here's what changed...

In my original version, I was caching a giant chunk of the template. This included the large database query (100+ records with 100+ fields), some Twig-side data manipulation, and the entire HTML portion of the template. Within the HTML, I am looping through those records and rendering a chunk of HTML for each.

In the new version, I am only caching the HTML loop. This is making a huge difference, bringing the page load time from ~15 seconds to ~1 second.

What I've found...

It appears that the offending line which was causing multiple cache keys to be generated is this one:

{% set entries = craft.entries.section('mySection').type('myType').limit(null).find %}

I still don't know why, and would appreciate an explanation if anyone knows!

  • Hard to tell if this is going to be a bug or expected behavior because of so many variables. Any chance you could get it down to a simple, reproducible test case? – Brad Bell Feb 10 '15 at 23:19
  • 1
    Wrap a cache tag around that {% set entries %} line, and that's basically my test case. If you'd like I can submit the whole thing to support@buildwithcraft.com (along with a DB export). – Lindsey D Feb 10 '15 at 23:36
  • Sent from the Dashboard! Lemme know if you need anything else. – Lindsey D Feb 10 '15 at 23:48
6

Update:

This has been fixed for the next (post 2.4.2725) release.


Turns out there is a bug in Craft where if you put cache tags around code that doesn't actually output anything, then duplicate keys get created in the craft_templatecaches table.

No workaround for it yet (other than to make sure you don't cache an empty string), but it's been logged as a bug.

| improve this answer | |
  • Copy that, thanks! Give a shout when it's patched, and we'll close this as a bug report. (In the meantime, it may still be useful for someone else to stumble upon.) – Lindsey D Feb 21 '15 at 6:07
  • Now it's 6 months later - is this bug still open? – gromgull Sep 8 '15 at 12:42
  • Still open... just make sure you're not caching an empty string as a workaround. – Brad Bell Sep 8 '15 at 17:34
2

I've run into this as well. As Brad points out, this does appear to involve a bug in Craft's cache handling. HOWEVER, if you resort to caching only your HTML output, you don't reap the benefit of actually caching that big database query... What has worked for me is providing an explicit cache key:

{% cache globally using key craft.request.path ~ 'someDescriptive/identifyingName' %}

(I've been using descriptors in my cache keys because I've been needing to clear out various subsets of them very frequently, but you don't have to if you just have one {% cache %} fragment on a page.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.