[Resolved] WP Super Cache: causes time out on file delete with RackSpace CloudSites
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!
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?
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.
Update: we can’t repro it with a site that has no traffic. I’ll run it on a live site with debug ON
It could just be that the load on your site is too much? Did the debug help at all?
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)
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).
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/?
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).
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.
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?
Oh well, a shorter cache timeout will help anyway. If you continue to see the timeouts then reduce it further.
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?
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!
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).
- The topic ‘[Resolved] WP Super Cache: causes time out on file delete with RackSpace CloudSites’ is closed to new replies.