Thread Starter
sqlwiz
(@sqlwiz)
Here is a test several minutes past expiration. Note the negative max-age. YSlow Components gives me the following Response Headers:
Date Mon, 01 Feb 2010 17:41:47 GMT
Server Apache
Accept-Ranges bytes
Cache-Control max-age=-213, public, must-revalidate
Expires Mon, 01 Feb 2010 17:38:14 GMT
Vary Accept-Encoding,Cookie
X-Pingback http://nnn.nnnnnn.nnn/xmlrpc.php
X-Powered-By W3 Total Cache/0.8.5.1
Pragma public
Content-Length 14347
Keep-Alive timeout=5, max=99
Connection Keep-Alive
Content-Type text/html; charset=UTF-8
Content-Encoding gzip
Thread Starter
sqlwiz
(@sqlwiz)
So the ugly reality appears to be this.
Every page on the site got cached within 5 minutes, therefore no page was kicking off wp_cron once the max lifetime was exceeded.
The problem is (as with all disk based caching plugins) is that if there’s no cache miss to invoke PHP and thereby garbage collection as a result, this case can occur. Apache’s mod_rewrite directive limitations make it so and it is not for a lack of desired remedy that this case exists.
A cron operation or a batch script invoked via RewriteMap are possible remedies to this issue, but they are not trivially deployed for most hosting scenarios. And in the case of the batch script, the expense of the operation, is not a performance win compared to invoking PHP to work with the file system and may not scale in practice whatsoever.
If you have suggestions, I’m all ears.
Thread Starter
sqlwiz
(@sqlwiz)
I certainly see your point and do not have any ideas yet.
In our case, I might like to setup a cron entry to execute a wget on wp-cron.php at each blog/site.
I’m still trying to understand the logic used to clear the disk cache in an MU environment. The files do not always get cleared when expected based on my current understanding. In addition, files from blog A are sometimes cleared by visiting blog B.
Thread Starter
sqlwiz
(@sqlwiz)
So I’ve found out the following about the disk enhanced page cache expiration in WPMU:
There is one wp_cron entry per blog called w3_pgcache_cleanup that executes at the “Garbage collection interval:”. It goes through the /wp-content/w3tc/pgcache directories removing files that are older than “Maximum lifetime of cache objects:”.
There appears to be no way to trigger the removal of an individual cache entry when updating posts. Editing and re-publishing a post creates a “One-off event” wp-cron entry called “do_pings”, but nothing is created for pgcache.
Note that when w3_pgcache_cleanup runs, it is removing files from all blogs in the WPMU site, not just the blog that wp_cron ran from. I do not know if this is by design or a side effect from using the mu_multi-site plugin, but it is beneficial.
wp_cron can be triggered from the linux command line with
wget http://www.domain.org/wp-cron.php
Indeed, the garbage collection logic for disk enhanced page caching could be improved.
Was this testing done with browser cache disabled?
Thread Starter
sqlwiz
(@sqlwiz)
Browser cache is enabled.
Humor me and test with it disabled please.
Has there been any solution for this issue? We are having the same problem of not updating on expiration on our website. Although i have set it to 3 mins, it still seems to be refreshing the cache every 60mins :/ garbage collection is set to 300 secs.
By the way, thank you Frederick for the great job and the support you’re doing here on these forums 🙂
If you could submit a bug submission form from the support tab of the plugin that would be best.
