Problem/Motivation
The Redis Report available under /admin/reports/redis is a great tool. But wouldn't it be nice to be able to access those data via the command line, with Drush?
Steps to reproduce
Proposed resolution
Add support for accessing the data from the Report page via Drush.
Remaining tasks
Decide if it would be an improvement.
Evaluate if adding Drush support is a big task, or not.
User interface changes
API changes
Data model changes
Issue fork redis-3555973
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
berdirYes, I've been thinking about this for a while and finally got something started. Unfinished, but this already does have some very useful bits that the web report doesn't have, because I'm more comfortable doing something slower here as I have a progress bar and no/higher execution limits.
Specifically, it extend the bin info to include the size (as reported by redis with MEMORY USAGE) as well as the number of expired and invalidated cache entries:
"Fun" fact: This is the result of umami on Drupal core 11.x, a "wget --mirror" to populate the cache and then saving a single article node. This directly invalidates 90% of the page cache, 50% of the dynamic page cache and 30% of the data cache (views results). That's due to the invalidation of the node_list cache tag. Shows nicely that if you have semi-frequent content updates and use views on many pages in blocks and so on, it's crucial to avoid the node_list cache tag and use something like views_custom_cache_tag.
Comment #5
berdirComment #6
berdirPretty much completed what I wanted to do with this, cache tags now also include number of usages in cache entries and added render cache varations and warnings:
Comment #7
berdirDid some testing with a backported version of this on a production project. it can take a while to collect the data, 120s for us with 100k keys.
However, it exposed a bug with the scan implementation, it may return an empty list, but the loop must be continued until the iterator is 0 again. see https://github.com/phpredis/phpredis?tab=readme-ov-file#scan. there's also the automatic retry option,
Comment #8
ressaThe examples in your last comments look great @berdir, thanks! And also nice that additional bits of info might be included, like the size, expired and invalidated cache entries as well.
Interesting observation and insight about cache invalidation, thanks for sharing. Just for those who are not sure (like myself) but how would you easiest avoid using node_list cache tag, and use something like views_custom_cache_tag instead -- can it be set in the View, or some other way?
It was on my list to try out the MR for the new Drush command, but I'll wait until the Status changes.
Comment #9
berdirhttps://www.drupal.org/project/views_custom_cache_tag should explain fairly well on how to use that, #support might also be to able with specific questions. Yes, essentially you configure it in the view and instead of invalidating all node views every time any node is saved, you just invalidate article lists if it's an article.
Comment #10
ressaVery cool module, thanks for making it and a fast reply, I really appreciate it. It might be a Drupal core candidate, since invalidating cache tags for all nodes seem to broad ... but that can always happen in the future eventually, if the number of installs continue to grow.
Comment #11
berdirWe're getting off topic, but while I think views_custom_cache_tag should be used on all non-trivial sites with lots of content and updates, it's a developer tool. It's not rocket science, but you need to understand cache tags and add the correct strings by hand. There's #3055371: Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate to do that automatically in core for node types, but there are many possible configurations in views, getting this right is hard, and if it's wrong then that means that lists aren't updating when they should, which can be a major problem.
The scan issue should be fixed.
Comment #13
berdirMerged, added some docs and hints on how to use this information.
Comment #15
ressaFantastic, thank you! I am looking forward to have this tool available.