Object Caching changes in 2.8.6

Object caching speeds up performance by storing complete objects, like WP_Post or WP_User, so they don’t have to be rebuilt from database queries every time they’re needed.  There are two primary storage methods for object caching:

• Memory-based caching (e.g., Redis, Memcached): This method stores cached objects in RAM, offering faster performance and avoiding disk I/O overhead.
• Disk-based caching: This method writes cached objects to files on the server’s disk, which is useful when memory-based caching is not available or the cache is too large to store in memory.

Most high-performance setups use memory-based caching for object storage, but shared hosting providers typically don’t offer Redis or Memcached due to security concerns, as they can’t guarantee that cache data won’t be accessible to other users. This leaves disk-based caching as the only option for shared hosting.

The Issue in Version 2.7.6

In W3 Total Cache version 2.7.6, we made updates to the object caching system to improve efficiency. These updates aimed to cache more objects, with the goal of reducing redundant database queries and improving load times. The logic was simple: if more objects were stored in cache, fewer database queries would be needed, resulting in better performance. However, what we didn’t anticipate was the impact this would have on users relying on disk-based object caching. By caching more objects, more cache files were created, which led to some users hitting their inode limits—a restriction set by hosting providers on the number of individual files a user can store on their server.

What Are Inodes and Why Do They Matter?

An inode is a data structure used by file systems to store metadata about a file. Every file on a server requires an inode, and hosting providers (especially shared hosting providers) enforce inode limits to prevent excessive file storage. When a user reaches their inode limit, they may be unable to create new files, which can lead to website errors and degraded performance.

Our Attempts to Address the Problem

Once we identified that some users were running into inode limits due to excessive cache file creation, our initial fix was to adjust the garbage collection interval. The garbage collection process clears out old cache files at set intervals, freeing up disk space and inodes. However, even with this adjustment, we continued to receive reports of users running into disk space and inode issues.

Our Solution in Version 2.8.6

After discussing several possible solutions, we decided that the best approach in version 2.8.6 was to:

1. Automatically disable object caching if it was configured to write object cache files to disk.
2. Show an admin notice informing users that the feature was disabled automatically, with a link to this blog post for further details.

While we generally avoid making configuration changes on behalf of users, we felt that this case warranted an exception. For most websites running on shared hosting, using disk-based object caching is not recommended because it can lead to excessive file creation and performance issues. We strongly encourage users to switch to a memory-based caching solution like Redis or Memcached if their hosting provider supports it.

What This Means for You

If W3 Total Cache automatically disabled object caching on your site because it was writing cache files to disk, you still have the option to re-enable it if you prefer. This automatic disablement will only happen once, meaning that if you turn it back on, W3 Total Cache will not disable it again.

We appreciate everyone’s feedback on this matter, and we sincerely apologize for any inconvenience this has caused. Our goal is always to improve performance while maintaining a seamless experience for our users. Moving forward, we are taking steps to enhance our automated testing processes to catch potential issues like this before release.

Thank you for your understanding, and we appreciate your continued support as we work to improve W3 Total Cache.