- 🇺🇸United States lhridley
Adding this contrib module, as it seems relevant to the discussion: https://www.drupal.org/project/filecache →
I've used this module to resolve an issue related to database caching performance impacts and database stability issues. The particulars of the use case were:
- two newly built Drupal 9 sites, launched within a day of each other, both receiving a high amount of traffic and constant edits to the content by content maintainers
- Both sites made heavy use of Layout Builder. One was built with a large number of components created in Storybook and leveraged Layout Builders "dynamic" page configuration (stored as part of content), the other used a smaller set of components and more heavily leveraged Layout Builder page templates (stored in configuration)
- Both sites were hosted in a containerized environment managed with Kubernetes (that did not scale horizontally, a discussion for another day) using Google Cloud SQL as a managed database option (Kubernetes may or may not be relevant, Google Cloud SQL definitely was)
- Within 48 hours the two sites were returning WSODs on a consistent basis. During troubleshooting the sizes of the backend database cache bins were excessive
- Both sites had Varnish caching, but due to the high number of page edits taking place, cached pages were consistently invalidated. One site (the one leveraging components in Storybook and Layout Builder dynamic page construction) had Memcached in place as well
- Before we could get additional caching layers in place, the constant thrashing of the backend cache bins brought the entire Google Cloud SQL instance offline, bringing all sites using the managed Google Cloud SQL instance offline as writes to the database were locked. In addition, the size of the cache tables made data recovery from traditional Cloud SQL backups impossible because the cache tables could not be imported, and a side consequence was that the Cloud SQL user table was lost as well, necessitating a total rebuild of the CloudSQL instance before manual imports of each individual database could be used to recover from backups. (not a glowing reference for Google CloudSQL, but the architecture of the overall setup may have been a factor).
To reduce the size of the cache tables immediately and allow for recovery from backup by truncating the cache tables in the database, we started looking for alternatives for the backend cache bins. Ran across this module and added it to both sites, adding a dedicated volume mount for file cache storage and management.
This solved the issue at hand, and worked beautifully. WE continually monitored the disk space usage of the dedicated volume mount and after two months of monitoring the usage leveled out to the point that we were able to adjust the sizes of the volume mounts downward, and implemented a monitoring alert system to alert the developer team when the disk space usage for that volume exceeded 70%.
To my knowledge this cache system is still in place for both sites.