• I’ve been testing WP-Super-Cache on some larger wordpress installs and while it does work better than virtually any other wp caching plugin I’ve discovered one weakness:

    On sites with a great deal of posts/pages, if you try to be efficient by having a very high expire time – it creates too many files for the cache pruning to work in realtime.

    This causes very high loads and wait-times for admin users who are just trying to make or edit posts.

    I’d like to modify this plugin so that the prune can be done by a real cron job or somehow spawn the prune as another php process – but I think the former is a better idea because if the pruning is done closer to the OS and not through PHP it will be faster with less load.

    If anyone has any already done this or just suggestions in general please let me know, thank you.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The simplest way would be for a cron job to execute a php script that calls the prune_super_cache function at regular intervals. Make it secret and put in checks for the calling IP address (localhost) and it should work fine. It may timeout if you have lots of files but you can take care of that by calling it more regularly.

    Thread Starter _ck_

    (@_ck_)

    Simple is nice and that’s a good quick workaround but PHP is notoriously bad at file handling and reading filemtime, etc. compared to working closer to the OS.

    https://ckon.wordpress.com/2008/09/16/filemtime-the-performance-killer/

    Ironically you commented on my post there three years ago so I guess we’ve come full circle ??

    So once I have your idea in place I will probably try to do something more native.

    I guess I should set the WPSC scheduler to a very high number to disable it.

    I am still not quite sure why I see WPSC trying to comb through all files and prune the cache the moment an editor goes into posts->add new regardless of the scheduler setting – I am missing something in the code somewhere but getting more familiar with it.

    Thread Starter _ck_

    (@_ck_)

    Okay I have an easy idea for pure speed without php, at least for linux hosted wordpress:

    nice +19 find /home/username/public_html/wp-content/cache/supercache/* -mmin +60 -delete

    fast cache delete by age, directly from linux, it’s perfect for running in cron (hence me adding the nice +19 in the front so apache and php get higher priority)

    You can test that line by first carefully removing the the -delete from the end to see which files it comes up with (obviously modify the directory too)

    By skipping the file type, it will include directories as well as it’s children, which I believe is the behavior we want?

    The +60 is obviously minutes which is adjustable

    Thread Starter _ck_

    (@_ck_)

    After some additional thinking, it occurs to me a parent directory to a file might be (significantly) older than the file that is needing deletion – ie. 2011/08/09/index.htm but 2011/08/ might have other subdirectories even though it meets the age requirements.

    So it still can be done, but has to be done in two passes, first just old files, then looking for empty directories to cleanup.

    1st pass

    nice -n +19 find /home/username/public_html/wp-content/cache/supercache/* -type f -mmin +60 -delete

    2nd pass

    nice -n +19 find /home/username/public_html/wp-content/cache/supercache/* -type d -empty -delete

    I think that should work nicely.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘[Plugin: WP Super Cache] Improving prune_super_cache to work in background with real cron’ is closed to new replies.