Title: [Plugin: WP Super Cache] Preload failures
Last modified: August 19, 2016

---

# [Plugin: WP Super Cache] Preload failures

 *  [Quibbler](https://wordpress.org/support/users/quibbler/)
 * (@quibbler)
 * [15 years, 5 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-preload-failures/)
 * With expiry at 1799 and preload at 1440 starting a preload generates all of the
   files (count in content and files present in file system).
 * But shortly thereafter all of the preloaded files disappear.
 * Also, there are some gaps in the documentation. The explanation of HOW to regenerate
   preloaded files does not describe WHY regular regeneration is worth doing.
 * My understanding of cache systems is pretty deep because I have written several
   for real-time systems. But I cannot determine some of the key features of your
   system. For example, what is the value of the short expiry time? In fact, what
   is the value of the expiry time at all? If cached values are going bad/stale/
   dirty, meaning the existing versions need to be discarded, then that should happen
   based on the trigger that rendered them obsolete rather than a fairly arbitrary
   timer setting. If it is not possible to catch the triggers, then the expiry time
   is just an expression of the owner’s willingness to serve up stale info for some
   period in order to reduce the processing load. I believe it would be worth clarifying
   this issue.
 * And why is GC both automatic and very aggressive? Why not have a separate control
   for GC. Every 10 minutes is insanely often for most sites. Even every 1799 minutes
   is overkill for most sites. And according to the documentation the only longer
   alternative is no GC.
 * All of expiration, GC, and preload regen should be schedulable at off-peak hours.
   It may be necessary to have a short expiration for some reason that I do not 
   comprehend. But who will be hurt by a daily or weekly GC? That is not possible
   with the existing controls.
 * And the documentation leaves many issues unclear re cached files and preloaded
   files. The doc makes them appear to be distinct. But most cache technology uses
   the cache as the base system working in an on-demand fashion. Preloading is just
   an artificial kind of demand. In that classic arrangement the cache expiration
   time and the preload regeneration time must be the same or the system is busted.
 * I would be bappy to help with this, but I do not understand the existing implementation
   well enough to make corrective adjustments.

Viewing 4 replies - 1 through 4 (of 4 total)

 *  Plugin Author [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * (@donncha)
 * [15 years, 4 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-preload-failures/#post-1863569)
 * Are you using “Preload Mode” so the preloaded files aren’t deleted by the normal
   garbage collection? Even then they shouldn’t disappear shortly afterwards. Could
   you try the debug system?
 * You’re right about the documentation however but I figured it was self explanatory.
   If all files are preloaded then your site will be faster for any random visitor
   or search engine bot that comes along. In [this post](http://ocaoimh.ie/preload-cache-wp-super-cache/)
   from quite a while ago I explained what preloading was all about. I’ll update
   the readme.txt.
 * You’re right about garbage collection. It’s an “expression of the owner’s willingness
   to serve up stale info for some period”. Updating posts or leaving comments will
   update those particular posts but not others therefore sidebar widgets may show
   stale info. Some people don’t care and they set a really long expiry time. I’m
   pretty sure the documentation mentions something like this. You can set the GC
   to be longer than 1799 minutes too.
 * Scheduling GC and preload for off peak periods is on the todo list in my head.
   I haven’t had time to look at that yet however.
 * I’d love to hear if you have any more ideas or advice!
 *  Thread Starter [Quibbler](https://wordpress.org/support/users/quibbler/)
 * (@quibbler)
 * [15 years, 4 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-preload-failures/#post-1863572)
 * Bug response: Found the problem. The check box “WP SuperCache Settings”/Advanced/
   Advanced/Clear-all-on-post/page is definitely unchecked. Similarly the clear-
   on-error is also unset. But 350 MB of debug logs later, I found the cache being
   cleared after post/page (in my case page) updates. So the check box is definitely
   broken.
 * Feature-wise, even if the cache gets cleared preload mode should dictate that
   the cache be re-preloaded immediately following the clearing.
 *  Thread Starter [Quibbler](https://wordpress.org/support/users/quibbler/)
 * (@quibbler)
 * [15 years, 4 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-preload-failures/#post-1863575)
 * > You’re right about garbage collection. It’s an
    > “expression of the owner’s
   willingness to serve > up stale info for some period”.
 * OK, now I am confused. As I understand them GC and expiration are separate concepts.
   Expiration happens in the cache index. It indicates that the cache contents should
   not be use. GC happens in the file system. It cleans up expired file so they 
   do not accumulate.
 * > Updating posts or leaving comments will update
    > those particular posts but
   not others therefore > sidebar widgets may show stale info. Some people > don’t
   care and they set a really long expiry time. > I’m pretty sure the documentation
   mentions something > like this.
 * It may, but i read everything I could find but did not see it. Is there some 
   other place I should be looking for doc?
 * > You can set the GC to be longer than 1799 minutes too.
 * Not according to the settings labels which state that
    GC_interval = (expiration
   >1800) ? 600 : (expiration+10) which cannot be larger than 1810 seconds. (1809
   if you distrust the interpretation of “>” as really being “>=”).
 * So how can I set GC to be larger than 1810?
 * Again we have to be careful about separating expiration and GC. For example, 
   on one of my sites I might want to avoid staleness so I set expiration at 300
   seconds, but I am not worried about old cache files hanging around so I want 
   to set GC to 2,500,000 seconds (about a month). Definitely no more frequently
   than daily and then only at my off-peak time of day.
 * So how would I accomplish that (fast expiration, slow GC) with the existing UI?
 *  Plugin Author [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * (@donncha)
 * [15 years, 4 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-preload-failures/#post-1863581)
 * Supercache is more simplistic. Old “stale” files are served until cleaned up 
   by the Garbage collector. That’s one reason why it runs every 10 minutes when
   the expiration is long.
 * You can set the expiration really long, much longer than 1800 seconds. The GC
   process will fire up every 10 minutes to check if there are files older than 
   that limit then… If you have preload mode on then those preloaded files aren’t
   touched until after the next preload.
 * Fast expiration isn’t really required as updating posts and leaving comments 
   deletes the related cache files. I could do a check for the age of the file before
   serving it but that would mean processes that serve requests (and this wouldn’t
   work in mod_rewrite mode) writing to the filesystem.

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘[Plugin: WP Super Cache] Preload failures’ is closed to new replies.

 * ![](https://ps.w.org/wp-super-cache/assets/icon-256x256.png?rev=3506220)
 * [WP Super Cache](https://wordpress.org/plugins/wp-super-cache/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/wp-super-cache/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/wp-super-cache/)
 * [Active Topics](https://wordpress.org/support/plugin/wp-super-cache/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/wp-super-cache/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/wp-super-cache/reviews/)

 * 4 replies
 * 2 participants
 * Last reply from: [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * Last activity: [15 years, 4 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-preload-failures/#post-1863581)
 * Status: not resolved