Yup. I can confirm it. That is what i do all the time. I find it is much quicker to do it myself than wait on it clearing when i have too many files.
Thanks for that confirmation.
However, it still bothers me that there would be 19k (1.6GB) cached files dating back 3 months when I have my QC config option “Cache Expiration Time” set to 3600 seconds (1 hour).
The site seems to be performing well. I’ll try to test if it is actually presenting one of those old files to a non-logged in user. Any tips on how to prove that?
Thanks, Ron
Really? Dating back 3-months? If that is the case then DEFINITELY something is wrong. Yea on my side it does go about refreshing them when they expire. Of course, do realize that if no one returns to the page that needs refreshing this old cache file can remain dormant in the folder forever (assuming you dont make use of QC’s auto-cache feature).
I am not sure how big your site is (existing pages) so maybe 19K files is normal, but if not, then it sounds to me you may be caching GET/POST requests too which can get quite sizable as people begin to use a search box or even write a comment. By default though i believe this plugin shouldn’t be caching those.
If these very old files still exist can you view one of them, scroll to the bottom of the file, copy its URL and try testing (in your browser) to see if that same old cache file is returned (view source code and scroll to the bottom to see if the time stamp is the same as what was shown in the file). I am curious to find out if QC will begin caching a new copy of the page.
On the flip side, if you want to test a particular page but dont know what its qc-c.* file is you can use an online MD5 calculator to help locate the file. Assuming you aren’t using a salt (by default it is left blank) the name of the qc-c-* file is postfixed with MD5 hashes of the url of a page. So for example if my page was: example.com/about/ (notice i dont use http:// at the beginning) then it’s MD5 hash would be: 8f17b1f11ffd5b7316d4e404fb533a47, resulting in a QC qache file named: qc-c-8f17b1f11ffd5b7316d4e404fb533a47-8f17b1f11ffd5b7316d4e404fb533a47-617a9471507f0eb608f3858291adb70f
Format:
qc-c-{MD5 of Page URL}–{MD5 of Page URL}–{MD5 of Site Host Name ending with a Slash}
The “GET Requests” option is “True (Don’t Cache)” so that’s not an issue.
Pasting in the URL from the QC comment at the bottom of a stale cache file does recreate a new cache file (with the same MD5 name), so that’s good too.
I do make use of the autocache feature which, as I understand it, will immediately cache a page that is changed so no anonymous visitor has to experience that 1 or 2 second first hit delay.
Also, on that site we get 10k hits per day and I’m sure they are not all unique.
So that leads me back to the question about why so many old files. I thought the QC “garbage collector” is supposed to run every hour, and since my expire time is set to 3602 seconds, there should not be any files older than 2 hours + 2 minutes. There is a scheduled task for this in the wp_options table. I’m pretty sure my wp_cron is executing normally since I do get wp plugin update notices.
My best guess is I think the garbage collection routine is not working, and there is some not-so-unusual (since I’m not the only one experiencing this) combination of settings that make it not run. Do you think it is by design that unvisited pages/files would remain dormant in that folder forever? Isn’t garbage collection supposed to get rid of that to prevent bloat?
I will have a look at the code and see what the garbage collector is up to.
By the way I do appreciate the depth of knowledge you (kellog9) and other posters have on these very technical subjects. I read that primothemes/websharks/s2member (the plugin author) is making some changes. Do you work for WebSharks? If not, why is there no input from them?
To all orphaned Quick Cache users…. I’m seriously considering switching over to WP Super Cache since the author Donncha O Caoimh is a bonafide automattic guru and should be around a while.
And although many big sites swear by W3 Total Cache, I’ve never gotten it to work properly since it seems way too complicated and I think it does some weird things with caching database queries. Everytime I’ve tried to activate and configure it, my sites come to a grinding halt, but maybe that’s because there is a lot of intitial overhead for it to get the magic going.
The only way that I’ve found so far to reliably and quickly clear the cache in Quick Cache is to simply turn it off for a couple of minutes, look in filezilla to see that the wp-content/cache directory is empty (except for that mutex file) then turn it back on.
My motivation for deleting those 19k old files is that it takes way too long to backup (using filezilla) and they are not critical files.
19K, why that’s chicken feed compared to my 23MB – yes, MB!! 🙂
I run Quick Cache on several sites and I’ve never seen this happen, and I have them all with the same settings – that is, out of the box settings.
I foolishly hit Clear Cache instead of deactivating the plugin and deleting it, so here I am, over ten minutes later and the Clear Cache is still running and the site is no longer accessible.
Oh, and all the sites with Quick Cache are on the same Hostgator server, so there shouldn’t be any cPanel or server settings different on this site…
I’m loath to do anything while that Clear Cache button is running, but at some point I’ll get up the courage to hit Deactivate…
Ron, I found this in your other thread:
I just did an experiment to clear my 19K (1.6GB or 3+ month’s worth) of old cached files:
A. Yesterday the “clear cache” button on the top admin bar never completed.
B: Using filezilla to delete the contents caused filezilla to hang (or I just gave up)
C: Just now, I changed the cache expiration time to 3601 and within seconds all stale cached files automagically disappeared. Yay!
I experienced A and B and when I did C, it did indeed clear the cache itself and all is working again.
I’ll keep an eye out now to see that it continues to be cleared each hour.
Thanks so much for posting your information!!
bravenewniche… I’m glad my experimentation has helped you.
Well, I just checked again and my oldest stale cache files were from 2 months ago, the file count was 32k and the disk space used was 3.9GB.
Changing the cache expiration time (from 3601 back to 3600 this time) did remove all the files within a minute or two without ever disabling the cache. So that’s a nice workaround, but not a fix.
It seems that this plugin must be ignoring that config value, except when it is changed. OR… maybe it is working making new cache files without deleting the stale ones. The description of that setting (in the plugin) doesn’t say anything about actually removing old files.
Other than having to do this housekeeping, the plugin has been solid: it seems to do its job efficiently, and stay out of the way.
My cache folder had 600k files using 30GB of disk space!
Obviously, my cache expire time was something like 48h and old cache files never were deleted.
I had to create a wp- cron to do that for me.
