WP Super Cache: causes time out on file delete with RackSpace CloudSites

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

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)

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,

I forgot: I’m not using preload.

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?

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