WordPress.org

1. Hubert
   Member
   Posted 4 months ago #

   Hi Donncha,

   We have noticed that WP Super Cache has caused a number of server time out on RackSpace Cloud Sites. One that we were able to reproduce consistently was when trying to delete a media file (.jpg, 50KB). The admin page would time out every time.

   Turning WP Super Cache OFF or reverting back to 0.999 fixes the issue. If you're interested in debugging this for Cloud Sites users, I should be able to create a copy of the site on a dev server so that you can look into it.

   In the meantime, we'll stay with 0.999, which works well (btw, is 0.999 WP 3.31 friendly?)

   Thanks for making this plug-in!

   http://wordpress.org/extend/plugins/wp-super-cache/

2. Donncha O Caoimh
   Member
   Posted 4 months ago #

   Did you try the debug log in the plugin? Maybe there's something there activating a clear cache? Could even be another plugin that's triggering something new in the plugin?

3. Hubert
   Member
   Posted 4 months ago #

   Hi Donncha, I'll build a debug site, and hopefully we can repro the problem on a site that has no traffic. I'll be able to give you an admin access if you want.

4. Hubert
   Member
   Posted 4 months ago #

   Update: we can't repro it with a site that has no traffic. I'll run it on a live site with debug ON

5. Donncha O Caoimh
   Member
   Posted 4 months ago #

   It could just be that the load on your site is too much? Did the debug help at all?

6. Hubert
   Member
   Posted 4 months ago #

   Donncha, the "good news" is that I was able to reproduce the issue consistently on a production site. At the moment, there is no perturbation for our readers, and this causes only a mild annoyance to the editors. A few interesting things:

   1/ Once WP Super Cache 1.0 is activated, we consistently bump into a problem if we try to delete an image from the media library (it would time out, basically).

   2/ However, this happens ONLY if there are a relatively large number of files in the cache. If I delete the cache, I can delete media files again.
   Now that an empty cache and a busy cache yield different outcomes, I may be able to reproduce this in a dev-environment. Looking at the log, I don't see anything that caught my eye (except this below), but I can send a 5MB log file over, if you're interested - contact me via Gmail or Facebook as we're connected on both.

   It looks like the reason why I could not reproduce this on a test site was because the cache had not been used enough -- sneaky! Again, if I switch back to 0.999, this goes away for good, even with a cache directory that is well occupied.

   Does this sound like a real issue to you?

   /wp-admin/post.php?action=delete&post=33853&_wpnonce=90b0c355e3 rebuild_or_gc: rename to /PATH-TO-WWW/wp-content/cache/supercache/[DOMAIN]/[CATEGORYPREFIX]/[CATEGORYNAME]/index.html.needs-rebuild

   /wp-admin/post.php?action=delete&post=33853&_wpnonce=90b0c355e3 gc: could not delete /PATH-TO-WWW/wp-content/cache/supercache/[DOMAIN]/[CATEGORYPREFIX]/[CATEGORYNAME] as it's not empty: index.html.needs-rebuild

   Some stats, to give you an idea (not huge, right?):
   wp-content/cache (245 files, 5.39MB)
   wp-content/meta (248 files, 121KB)
   wp-content/supercache (100+ 3MB)

7. Hubert
   Member
   Posted 4 months ago #

   Update: Ok, I tried to populate the cache of the dev machine with a couple of hundred pages, but I can't make it time out. Unfortunately, there are a couple of plug-ins that I have not fully activated on the dev machine, like JetPack, Vaultpress and WPTouch.

   I'll ask the Vaultpress folks if it's OK to activate/deactivate on the production site to run tests, and I think that I can de-activate Jetpack when I want on the production site because we just use it for WPStats.

   At this point, only the production sites are encountering the issue, but to answer your previous question, I don't think that it is a matter of load. We have a site that has 4X the traffic and it runs just fine with the same setup -- and gets into the same trouble if updated to WP Supercache 1.0 (works fine with 0.999).

8. Hubert
   Member
   Posted 4 months ago #

   Donncha, I'm working on a new theory, but I would need more info: do you think that: "deleting a media file" or "creating a new post" would cause WPSuperCache to flush the cache, fire the garbage collector or do something that would be slower if there are a lot of files in /wp-content/cache/?

   Thanks,

9. Hubert
   Member
   Posted 4 months ago #

   Ok, I looked into the code and I wanted to ask you what you thought of this idea:

   Is there a chance that if there are enough files in /wp-content/cache/ that the various checks and prune operations of WP-SuperCache may time out after 30sec or whatever PHP.ini is set to? It seems that there are a few places with the potential for that, but I don't understand your code enough to be sure.

   If that's the case, lowering the cache expiration time may help (currently 2hrs).

10. Donncha O Caoimh
    Member
    Posted 4 months ago #

    Those checks could definitely time out! I wonder if it's the new preloading of tags that's causing the problem. In 0.9.9.9 only posts were preloaded but now taxonomies (categories and tags) are too. I'll make that optional on the preload page but in the meantime reduce the cache timeout and don't have "preload mode" enabled.

11. Hubert
    Member
    Posted 4 months ago #

    That may be it. also we have thousands of tags, so this cannot help. Right now, we can always flush the cache to "fix" the situation, and I've reduced the Cache Timeout to 3600 secs, so we'll see how we do tomorrow when traffic picks up again.

    That said, in the longer term, the issue may show up again. For example if we become more popular in search engines, we will get hit at random places and we have tens of thousands of pages. I think that if this happens (hopefully it will!) we maybe in trouble again and reducing the timeout may not help.

    I have a question that may be naive: if /wp/admin/ is not cached, why does the plug-in do all the checks when browsing those pages?

12. Hubert
    Member
    Posted 4 months ago #

    I forgot: I'm not using preload.

13. Donncha O Caoimh
    Member
    Posted 4 months ago #

    Oh well, a shorter cache timeout will help anyway. If you continue to see the timeouts then reduce it further.

14. Hubert
    Member
    Posted 4 months ago #

    Yes, I'm trying that. Some stats:

    - We can go as high as 5000 WP Super Cache cached page, then we start getting in trouble
    - WP-Cache has about 120 pages cached

    As far as I can tell, it gets linearly slower to generate the cache stats, and the issue mentioned in this thread gets worse with more files.

    It sounds like ver 0.999 should get in the same kind of trouble, but it doesn't. Btw, do you know anyone who has been using WP-Super-Cache with /wp-content/cache/ mounted on a RAMdrive?

15. Donncha O Caoimh
    Member
    Posted 4 months ago #

    If you have a local filesystem on the server there's not much point putting the cache in RAM. The OS will cache any frequently accessed files in RAM anyway. I tried a RAM disk a while back and it didn't really make things faster.

    You didn't see the same slow down when you had 5,000 cached files with 0.9.9.9? That's very odd!

16. Hubert
    Member
    Posted 4 months ago #

    Thanks for sharing your experience with the RAMdisk. I was interested by the "near-instant" seek-time, which may make the prunes and checks a lot faster. If it didn't work for you, it probably won't work for me.

    That's correct, 0.999 never lead to a timeout in the /wp-admin/ area, and if I revert now, stuff just works as one would expect. We had to revert back to 0.999 for the bigger website, but we kept a smaller one with 1.0 to run the tests we have discussed here. If we revert the smaller site to 1.0, the problem goes away completely.

    But this gave me an idea: I'm going to setup our staging site so that it preloads a bunch of files (let's say 5k+), then I should be able to consistently repro the issue (I hope).

17. Hubert
    Member
    Posted 4 months ago #

    Ok, as expected, reducing the cache duration (to 1800sec from 7200sec) lowers the number of files by 66%, and makes the problem go away for now. So, we trade off CPU for IO speed I guess. I still don't know why 0.999 behaves better than 1.0

    As for my plans of using the preload to populate the cache on the dev machine, it looks like preload doesn't work on my particular install. I'll hop onto this thread to follow-up. http://wordpress.org/support/topic/plugin-wp-super-cache-preloaded-pages-not-created-until-user-visits?replies=9#post-2536751

    If someone else has the same issue than the one described for this topic, the conclusion is: don't let the cache grow too much, that was the reason for the time outs in wp-admin pages ("create new post", and "delete a media file" in my case).

    Action items: lower expiration time until the cache population comes back to a more manageable level.

18. Hubert
    Member
    Posted 1 month ago #

    Donncha, after upgrading to WP 3.3.2, I gave WP SuperCache 1.0 another try, and we bumped into issues right away, even with a TTL of 700. Also, we have about 1000 pages cached, at most.

    The symptoms are similar: "Add New Post" page times out, and looking at the PHP logs, we've been also getting many "database server has gone away" errors when trying to create a new post.

    I really don't see how WP SuperCache could be related to that "DB server gone away" error, but after reverting to 0.999, those PHP errors on "Add New Post" never showed up again, and the "Add New Post" page never times out.

    I have WP SuperCache 1.0 working on lower traffic sites (same hosting details + template) without any issues, and I am unfortunately unable to reproduce this on a dev site that is not under load. In any case, I thought that I would update this thread in case someone else bumps into the same issue, or in case you had an idea that you would like to discuss. Thanks!

19. Hubert
    Member
    Posted 1 month ago #

    Actually, and idea came to mind: the storage system over there is a SAN, so while it is much better than a DYI NFS system, is there a chance that we coudl saturate or cause problems to the network interface? This may be the reason why WP SuperCache ultimately affects the DB connectivity... (?)

20. acrain
    Member
    Posted 1 week ago #

    We're experiencing the same issue and haven't been able to resolve it. Running WPSC 1.0 on WP 3.3.2 multisite, our most heavily trafficked blogs in the network will run into this when a user attempts to create a new post. The /wp-admin/post-new.php takes ages to load, and when it finally does load, it is topped with a WP message saying "Thanks for updating WordPress" or something to that effect. Then, when a user clicks either "Publish" or "Save Draft", they get the error page ("Are you sure you want to do this? Please try again").

    The only resolution at this point is to clear the cache, which resolves the problem temporarily.

    During the 2+ minutes while the /wp-admin/post-new.php page loads, Super Cache logs show ~20,000 entries like this:

    14:54:36 /blogs/tv/wp-admin/post-new.php gc: could not delete /<...removed...>/wp-content/cache/supercache/cincinnati.com/blogs/bengals/2012/05/14 as it's not empty: palmer-discusses-moving-on-with-dan-patrick

    I'm happy to share logs.

    During the same period, the WordPress debug log (WP_DEBUG true, WP_DEBUG_LOG true, logging to wp-content/debug.log) shows entries like this:

    [21-May-2012 14:23:42] PHP Notice:  Undefined index: HTTPS in /<...removed...>/wp-content/plugins/wp-super-cache/wp-cache-phase1.php on line 526
    [21-May-2012 14:23:42] PHP Notice:  Undefined index: HTTP_X_FORWARDED_PROTO in /<...removed...>/wp-content/plugins/wp-super-cache/wp-cache-phase1.php on line 526
    [21-May-2012 14:23:42] PHP Notice:  Undefined variable: wp_cache_object_cache in /<...removed...>/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 980

    Some other possibly userful info: Cache timeout is 3600. Storage is NFS. We use mod_speling (so maybe there's an issue noticing/removing oddly cased files?).

    I hope this is helpful.

    Thanks!

21. Donncha O Caoimh
    Member
    Posted 1 week ago #

    You shouldn't use NFS at all, that won't help. If your local machine has a small disk then use that if you can!

    Also, try the dev version, it's about to become 1.0.1..
    http://downloads.wordpress.org/plugin/wp-super-cache.zip

22. acrain
    Member
    Posted 1 week ago #

    Thanks, Donncha (and thanks too, I forgot to say initially, for a plugin that's been extremely helpful to us for years). Unfortunately, given our setup (multiple web heads reading from a pair of NFS-mounted file servers) we have no choice as far as NFS goes.

    I'll take a look at the dev version, but was hoping to hold off until the official release.

23. Hubert
    Member
    Posted 1 week ago #

    Donncha, NFS is clearly not ideal for disk-caching, we couldn't agree more, but in our case, we didn't have much of a choice, and version 0.999 still runs great.

    In our case, we're using an enterprise-level SAN that should be faster than regular NFS-mounted boxes. However, we still ran into the same type of trouble.

    Acrain > Have you tried reverting back to 0.999? In my case, it runs stable. 1.0 works fine on low-load sites, but on a high-traffic site, we bump into that timeout problem.

    Also, keep in mind that a high-traffic site may cause problems not only because of the load, but also because the long tail traffic will have a tendency to create more cached files, which ultimately seems to be what the problem is.

    Donncha, do you think that we could only cache pages that have been requested twice in less than X minutes, like Batcache does? Batcache uses some memory-based storage, so this is probably not a problem for them to keep counts - I thought that I'd ask anyway.

24. acrain
    Member
    Posted 4 days ago #

    Thanks Donncha and Hubert. I held off just long enough to get 1.1, which I can confirm seems to resolve the issue. We upgraded nearly a week ago and have yet to experience the issue.

    Hubert, since 1.1 came out quickly enough, we never reverted to 0.9.9.9, so I'm afraid I can't say whether it might have worked for us as well.

25. Hubert
    Member
    Posted 4 days ago #

    Thanks Acrain. We'll try 1.1 in the second week of June.

Reply

You must log in to post.