Limit number of cache files in cache bin directories

Current code makes sense to spread files amongst multiple directories.
Imho it's too complicated wrt the 2-level iterator (use basename instead) and ensureCacheFolderExists (which can be done when writing).

It does not yet address the main issue topic, limiting number of files.

could an error_log message be thrown and not an exception.
i have several instances where it is thrown but on refresh the subdirectory is created.
so maybe have it logged and treat it as a cache miss instead.

Rerolled patch to throw an error not and exception when a directory cannot be created.

I agree with @geek-martin. This should be renamed to "Create multiple subdirectories to improve performance". It is not about limiting files.

The last submitted patch, 10: 3001324-create-multiple-subfolders.patch, failed testing. View results →

Changed the name to: Create multiple subdirectories to improve performance
since it does not limit the number of cache files.

The patches and MR are related to that.

rerolled for filecache 1.1
changed throw exception to error_log
Use case:
There seem to be race conditions or "phantom errors" that appear. I do not want the site to crash. Instead log the error.

The last submitted patch, 14: 3001324-11-create-multiple-subfolders-log-errors-14.patch, failed testing. View results →

I've varied the subfolder name so that it takes the first 2 characters from an md5 of the file name. This will provide a wider range of folder names and help keep any subfolder from getting too big. (I was inspired by the Smarty PHP package which does something similar for the compiled templates.)

I based the patch off of the original MR which throws exceptions instead of logging errors - simply to minimize the number of changes in one issue (that can be handled in a new issue). I didn't go as far as trying to create a different branch and a different MR, but I could if this has traction. For now, we'll be using this to patch our sites.

We've been using my patch in #16 for the last few weeks and it has dramatically improved the system cleanup cron job. Previously it was getting hung up, running for hours. Now the cleanup cron job takes ten seconds or so. The size of the entire file cache is still about the same: half a G. So it's much better at garbage collection.

It might have also improved the speed of getting an individual cache item, but I didn't test the change there.