Document tables to move to redis caching

From our experience there is only one cache bin which should be excluded, but not for Redis specific reasons, rather because it is never cleared on `drush cc all` like all others and it may also experience/cause issues on multi-page forms, where their state may not be properly tracked with non-SQL backend.

    $conf['cache_default_class']              = 'Redis_Cache';
    $conf['cache_class_cache_form']           = 'DrupalDatabaseCache';

^ I agree with this type of default configuration.

My install has way too many cache bins and I wasn't interested in adding them one by one, to be used by redis. I found omega8cc's configuration and it's what I'm using in production now.

Indeed nicely spotted. Or you can just add this:

$conf['redis_flush_mode_cache_form'] = 0;

And you forms can then live into Redis safely and will only vanish when the TTL really expires.

I should add this mode per default for this bin.

Oh, this is already the default fallback for all bins other than "page" and "block". Nice nothing to do here. So to answer: it should be safe to use redis for cache_form storage (no matter how hard you run your hook_cron on the site).

The safest configuration is the default configuration actually; For an advanced configuration you do need to reed the full readme file. If you see anything that's missing in the readme, please explain and I'll improve it or just provide a patch. Maybe a word about the form cache should be added? But it will be in the right section, i.e. the one about flush mode; Not sure that everyone will read the documentation until this point.

I believe that the exception for cache_form was required to avoid issues in older releases, before the latest improvements in the module.

Also, I think that at least some "missing" parts of the README could be transferred from cache_backport where they are discussed (however they are not exactly consistent there).

I will do some readiing as soon as I can and try to improve this. If you already have any ideas about this, please provide patches.

Don't worry I never abandonned you! I just don't have much time to do this right now. Any documentation patch is welcome.

No problem, we're all busy. You're certainly one of the best issue queue maintainers on d.org, so thanks for your hard work ;)

It's easy to be efficient when you only have one really active module and only 10 issues, a lot of other people deserve much more credits than me for maintaining way bigger modules :)

I added a getting started section with basic working configuration, it's not exactly complete documentation but it should desambiguate some questions of this thread. See http://drupalcode.org/project/redis.git/commit/6821a25

I also added answer to Greggle's question, see http://drupalcode.org/project/redis.git/commit/71ba29f

See the README section there http://drupalcode.org/project/redis.git/blob/refs/heads/7.x-2.x:/README.... for a complete overview of both changes altogether.

Does anyone see any valuable additions to be made to this or does it answer all the questions?

I am marking this issue as fixed for issue queue clarity. I do hope the previous patches answers to the questions asked in here. Any additions are still welcome, of course, thanks again everyone!

I took a look at the new README.txt and it covers all the issues I previously had.

#1, I didn't know how to add redis as the default. This is now resolved.

#2. I might not want to add redis as default. and only add certain bins. There's an example in the readme on how to do that.

#3. You also cover the problem about cache_form for those coming from memcache, who previously explicitly avoided adding that table, because we're told not to. I still have that table disabled in my redis config, but from reading omega8cc's problem and then patch for solution, I may change this at some point.

Thumbs up from over here.

Thank you for your feedback, hope it helps other people too!

We have removed exception for cache_form on our servers and immediately got hit by broken module: https://drupal.org/project/ajax_comments

Not sure if this is a bug in that module and not sure if there are any other modules which could be affected, because after receiving a few complaints that people can't post comments on community sites etc, we have immediately reverted it back to:

$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';

Oh that's odd... Do you have any detail about what happened? I'd love to know what's happening there and be able to fix that on Redis' side if that's possible.

If you can give me a way reproduce I'll try as soon as can (which probably means in a few weeks...). Meanwhile, details, patches, explainations are welcome!

Thanks for reporting this

@omega8cc . The problem you ran into, is there's https involved? Switching between HTTP and HTTPS can mess up the form submissions.

I will do my best to debug this later in the week, but no, it was over plain HTTP connection. It resulted with javascript pop-up with unspecified error, completely blocking the form submission.

Good advice here: put two debug breakpoints in your bootstrap.inc file, one in _drupal_exception_handler() and one in _drupal_error_handler() first line of each (not sure of the names here, telling this from memory). Hit F5 on the exploding query with your debugger activated and you'll catch the unspecified error quite easily.

Should redis work correctly, and that bin not be configured to get purged or expired, I really can't see any reason it would be a problem if this data is stored in redis or database.

I would look into purges or expiries for these keys. Other than that, if they're full persistent and you're still running into this, you hopefully found a strange bug which is affecting other parts of redis cache.

I'm going to highly recommend by default, that cache_metatag is excluded by default.

That bin on my website, grows a couple megs a day. After about 4 days, it usually takes up about 1GB.

Here's that issue
#2062379: cache_metatag table grows too much.

Even with the fix in this thread, there's still issues. It's better, but still, data should really be in database if it's going to continue to grow.

Here's some more explaination:
https://drupal.org/comment/8266701#comment-8266701

Attached are my Munin graphs of redis memory usage. The spikes are only because of cache_metatag bin. When you see the graphs go down, this is because I have a script I run every once and a while to clear cache_metatag bin from redis.

Ouch, wtf!

Here are some updated graphs, after I switched metatag module to store in the DB instead of Redis.

Additionally to switching off redis for storing metatag cache, I'm also storing a bunch of new data in redis, which every single hook_node_view() for various view modes for which I'm storing statistics, refererer data for each page request, which users visited what nodes and lots of other data. So there's some increase in data in redis because of this. Otherwise it would be flatter.

Yes metatag is rather bugguy regarding its cache usage, I don't know if this has been fixed, but they'd store at some point in time an exponential number of cache entries (ouch).

@omega8cc are you still experiencing problems or can I close this issue ? Note that I'm switching it to fixed so it will close itself in a few days. If you still experience problems, please open a fresh issue, and please also consider trying to reproduce it with the new 3.0 release of the module.

I have not tested this yet, but I just assume that it was a very module specific issue, so I will report back only if I will be able to reproduce the problem with any other module. Thanks!

hi

For anyone reading, concerning @omega8cc issue, this module apdqc together with Redis by moving cahe_form to apdqc with $conf['cache_class_cache_form'] = 'APDQCache'; was my workaround ...