Static Cache/nocache tag error
#6781
Comments
|
It's always the same "key" |
|
It looks like this could happen when you use full measure caching: when you clear the regular cache, but not the static cache. Then the page (with the replacement placeholders) would still be cached in a file, but the actual replacements per region would be lost, as they are stored in the regular cache. That would lead to the error in this issue, where the |
|
@edalzell are you using full measure caching on this site? |
No |
|
Cloudflare? |
Yes |
|
What kind of static caching are you using, if at all? |
1/2 measure. |
|
@edalzell do you get this issue locally? |
Nope, but I normally don't do static caching locally. But it is enable on this site and I don't see it in my logs. But the live site gets waaaaaaay more traffic of course. |
|
Are there any workarounds (apart disabling static caching) yet? |
Currently no. So you are having the same issue? Do you have any additional info that might help? |
|
#7039 is likely very related. |
|
This is still a mystery. Can somebody share a full log file for this issue? Maybe there are more, possibly related errors in it to go on. |
|
|
Getting this too. Client sent me this: https://flareapp.io/share/KPglNBZ7#F75 |
|
@edalzell Are you using multisite for this one? |
Yes |
|
That's interesting. Can you show your |
'sites' => [
'default' => [
'name' => 'zakat.org (EN)',
'locale' => 'en_US',
'url' => env('APP_URL'),
],
'ar' => [
'name' => 'zakat.org (AR)',
'locale' => 'ar_DZ',
'url' => env('APP_URL').'/ar/',
],
'zfi' => [
'name' => 'zfinstitute.com (ZFI)',
'locale' => 'en_US',
'url' => env('ZFI_URL'),
'attributes' => [
'disable_pre_footer' => true,
'footer_below_wrapper' => true,
],
],
], |
|
I am experiencing the same error and it seems we are making progress in resolving the issue. Unfortunately, changing the configuration as suggested in the https://statamic.dev/static-caching#multisite documentation did not help to kick off multi-site |
|
That's super interesting, the only site this appeared on for us IS multi-site. |
|
Yep mine multisite too. |
Isn’t this exactly what zzzaaa was saying?
I‘m also experiencing issues with nocache on a multisite. |
|
We are also experiencing this on a website, together with #7039 We are experiencing this primarily on a page with forms (with livewire). @edalzell are you also using livewire? |
|
Can confirm I was using Livewire. |
|
Yes |
|
Curious. @zzzaaa and @j3ll3yfi5h were you also using Livewire? |
|
@jasonvarga Sorry, missed your comment: I don't use Livewire. |
|
Hey! So I was also having this problem, similar to others we're using Livewire here, no issues on local or in dev, just once it got into live. We're also not a multisite. It's not a fix by any means, but to stop the 500 error, I've done the following: vendor/statamic/cms/src/StaticCaching/NoCache/Session.php - Line 49: vendor/statamic/cms/src/StaticCaching/Replacers/NoCacheReplacer.php - Line 59: At a guess, I imagine it's just leaving some parts of the site missing (or re-generating it?), but for us it's better than the 500 error. Hopefully that's useful to someone in the meantime - let me know if you'd like me to send over any logs etc! |
|
Okay, so on from the above, I’ve found it does just return empty - so I’ve updated the code to behave slightly differently, that from what I can tell, seems to be okay. vendor/statamic/cms/src/StaticCaching/Replacers/NoCacheReplacer.php - Line 59: vendor/statamic/cms/src/StaticCaching/Middleware/Cache.php - Line 43: Obviously, this is by no means a fix, but it does seem to be working okay for us at the minute as a workaround. |
|
We see this issue on a increasing number of our statamic instances. We introduced more nocache Tags with the latest release. We are on half mesure, NO multisite, NO livewire, Redis for cache |
|
We have also reported this months ago to support@statamic.com, but they did not reply so far. I really hope this is something that is going to be addressed as it makes the cache pretty unusable on some instances. |
|
I'm a little frightened because now we use nocache around everything related to posts. This affects nearly every instance we were running. |
|
i reproduced it locally with file cache driver, no multisite, no livewire.
I didn't figure out how this situation could arise, in my production case perhaps due to redis key expiry. But there must be many ways as seen in this ticket here. I think cache should always be self-healing and should not depend on existence of specific files or cache keys. |
|
Would you be able to try out #8449 using a Composer patch? This solution will end up serving the uncached page if it runs into that error. (Similar to @Alt-Ben 's revision) It doesn't solve the reason the region is missing from the cache to begin with. Sounds like @mmodler is onto something with maybe Redis auto-expiring, but @edalzell's original support:details output shows he is using the regular statamic/file cache driver. So, maybe it's a race condition somehow? No idea really. |
The site this was happening on the most is our busiest site, and we don't pre-generate the static cache, so a race condition is a definite possibility. |
|
I don't think its related to redis "forgetting" keys. We have default TTL of two month and if redis would forget keys randomly, we will see lots of different cache errors. Here some examples from yesterdays log, the memory errors point to a race condition?
|
|
Do you see the same on your busy instance with file cache driver? |
|
I tried to use the composer patch which failed :) Digging deeper i found that there was a race fix with statamic 3.4 (#7722). Our platform is still on v3.3.68, so i think what we see is the locking issue? |
|
So just as a side note - we've tried all of the various caching methods in the live environment, from what I remember, the file cache didn't have this issue, but it was really really slow, like it wasn't actually doing the caching in the first place. When I swapped it to database (at the time), it returned to the speeds we'd expect, but then started getting the array key issue. We're also on 4.11.0 now, I've also just applied the patch, it normally takes a little while for the error to kick in, so I'll let you know whether we start to see it again over the next couple of days or not! |
|
I will try 3.4.11 + composer patch now. |
|
Just as an update, I haven't seen the issue return with the patch - so looks like it mitigates it for now? |
We don't see the exception in the logs since we patched. |
|
was very happy to see no more cache errors in the log files for the last few days. Today a colleague pointed out to me that our Redis instances are suddenly using 5gb of memory instead of 500mb. Since we only have a portion of the instances live already, this is a scary increase.
I already have the following findings:
=> The fix floods Redis for me, with file cache driver probably thousands and thousands of files would be created. |
|
@Alt-Ben Can you please check if you get flooded with response / nocache cache entries, too? |
|
@mmodler, so we're using memcached as the cache driver currently, it is basically maxing out the server swap memory (~2GB), but I don't think I've ever seen it not doing that whilst we've had memcached on. We also don't have anything that monitors it properly to be honest, so I couldn't be sure. But we've also got other issues around the volume of assets we have on this particular site that might distort any resource usage data anyway. |
|
After much degugging it turned out the problem had nothing to do with nocache. I was just too fixated on the nocache entries :) On one instance there were heaps of old urls with query parameters called, probably from a search engine bot. This led to the mass of response keys, the resulting nocache keys were then "expected behavior". As a quick fix I set |
|
So @mmodler are you saying the fix is okay? Your memory issue was unrelated to it? |
|
@jasonvarga Atm its ok. |
|
Just ran into this. Upgrading to 4.13.0 seems to have solved it for now. |
Bug description
We see hundreds of these entries in our logs, any ideas what the cause could be, or how to debug?
How to reproduce
Take a look at the logs on one of our sites (can provide if you want)
Logs
Environment
The text was updated successfully, but these errors were encountered: