Actually the cache is being stored with a hash scheme, so for each cached object, there are two parent directories. So you’re probably seeing about 2000 cached objects which sounds about right. Maybe there should be an option to store in a regular flat scheme for folks that have shared hosting that limits the amount of nodes?
Well i’m pretty sure i deleted more than 7000 files in my case. I will test more in the next version.
Not sure i understand the regular flat scheme. What that will change ?
The number of files would be the same. no ?
I had the same problem with W3Total cache (among other major problems).
With the current cache mode, you get two subfolders and one file for each cached item, eg 1/ab/cdefg, where cdefg is the actual file. You’re getting the extra subdirectories – not sure if that counts towards your total number of “nodes”. In another mode you’d get less subdirs, same amount of actual files.
Less folders will not help. Many (low quality and cost) hosting plan have also a per directory files limit.
The structure is ok as it is, imho.
Those files are ever deleted or expire ? What happens ? They grow until ….
This issue is marked as resolved, but it is anything but resolved. The “Enable Object Cache” option is marked “beta,” which provides warning that there might be unknown bugs. However, the issue here goes way beyond unknown bugs. You knew the selection would result in automatic creation of thousands files distributed through multiple sub-directories. It is ridiculous to put an option like that in production software without a clear and obvious warning about such radical consequences.
In my case that selection caused several serious malfunctions hours after the selection was made that took hours of troubleshooting to resolve. I only have myself to blame for being willing to test a new option for bugs. However, it is disappointing to find that you knowingly provided an option that created thousands of files in many new directories without warning.
I am not using discount hosting. I run my own state-of-the-art servers. Storage space is not an issue, but creating a huge mess on multiple servers is an issue. A selection that radical should not be released in a plugin used in production applications without a clear and obvious strong warning and explanation of known consequences. In fact, I don’t think it should be included in such a plugin at all. If you want to beta-test an option with such an extreme result, release a beta-test version of the plugin.
Bascially the object cache is caching the same objects over time. There should not be an increasing growth in the number of files or cache objects over time.
Not sure what CV is saying about an “extreme result”… this is the way a cache works, it stores objects in files that would otherwise have to be retrieved from a database and processed.
@caveatlector
I don’t see any “huge mess on multiple servers”, just a few thousands of files.
Don’t make a big deal out of it.
That probably is because you hadn’t enabled the option on multiple servers like I had. I had 16 servers malfunctioning and a total of 32,000 files scattered through a bunch of new directories to delete after troubleshooting to find the problem. Deleting the files was of course not a terribly big deal, but it would have been nice to know selecting an “innocent-looking” option on each server would result in all that.
Of course, it might not have been necessary to delete them, depending on the nature of the caching bug or bugs that caused the malfunctions, and whether I had wanted to use the caching. At this point I don’t want to use it, because time-to-first-byte increased about 20-percent on average compared to using only PHP oPcache, which of course caches in memory.
@caveatlector – simple fix, uncheck the box that says enable object cache and press the Update button.
@gatordog
Unchecking it doesn’t actually remove the files ….
(and it does correctly because removing all those files at once …..)
@caveatlector
Still i don’t get the “mulfunctioning” because of 32.000 files.
Also Opcache caches PHP code and nothing else.
Unchecking that box didn’t fix what checking it had caused. However, as explained above, I already fixed that myself a couple days ago.
The malfunction was that it was impossible to activate, deactivate or install new plugins on 16 servers until I eventually discovered after considerable troubleshooting that Gator Cache was causing the problem.
My intent was merely to give you the benefit of one user’s reaction to a change you made to the plugin. I have been very pleased with the simplicity, efficiency, and speed performance of Gator Cache compared to other caching plugins. You provide it free, so users have no basis to complain if you make changes they don’t like. If you think my reaction has basis then consider whether you should do anything different. If you don’t ignore it. I will continue to use Gator Cache so long as it meets my needs better than alternatives. I will just be a little less trusting and will carefully test new versions off-line before installation, which is something I normally do with new versions of plugins anyway.
Thanks for all the time you obviously have spent developing Gator Cache. It has worked very well until the issue we have been discussing.
There’s a purge button for the object cache in the next release. In the meantime, if you have shell access, you can go to your doc root and run rm -rf gator_cache_oc.
Otherwise, make sure GatorCache plugin is activated and the Object Cache is not enabled (unchecked). Then add this to functions.php and it’ll flush the cache:
GatorCache::getObjectCache()->flush();
Once the files are gone, you can remove the line of code.
As far as the amount of files, will have to do some further checks. Not sure if is not deleting properly or something to do with WP transients which I believe do hit the object cache. From what I gather, WP itself does not “clean up” transients.
