[Plugin: WP Super Cache] Preload failures

  • Quibbler

    (@quibbler)


    15 years, 4 months ago

    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)

    (@donncha)

    15 years, 4 months ago

    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 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

    (@quibbler)

    15 years, 4 months ago

    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

    (@quibbler)

    15 years, 4 months ago

    > 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)

    (@donncha)

    15 years, 4 months ago

    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.