List of cache bins that should not use memcache? [#1931794]

In the memcache documentation the cache_form bin is singled out as not being appropriate for volatile memcache storage.

My question is, are there other cache bins (potentially provided by contributed modules) that should likewise not be assigned to memcache, or is cache_form unique in this regard? If there are potentially other cache bins which should not be assigned to memcache, how does one go about determining them? What are the "signs" of a cache that should not be kept in volatile storage?

Taking this question into account, is it bad practice to assign all cache bins from contributed modules to memcache by default? Is best practice to keep the cache bins in database until memcache compatibility is determined?

Here are some example bins from the site I'm working on (I've assigned everything to Memcache except for cache_form):

$conf['memcache_bins'] = array(
  'cache_performance'     =>  'default', // performance_logging module
  'cache'                 =>  'default',
  'cache_admin_menu'      =>  'default',
  'cache_apachesolr'      =>  'default',
  'cache_block'           =>  'default',
  'cache_bml'             =>  'default',
  'cache_bootstrap'       =>  'default',
  'cache_field'           =>  'default',
  'cache_filter'          =>  'default',
//  'cache_form'            =>  'default',  // This cache bin should not be assigned to volatile storage
  'cache_image'           =>  'default',
  'cache_libraries'       =>  'default',
  'cache_mailchimp_user'  =>  'default',
  'cache_menu'            =>  'default',
  'cache_page'            =>  'default',
  'cache_path'            =>  'default',
  'cache_rules'           =>  'default',
  'cache_token'           =>  'default',
//  'cache_update'          =>  'default', // Core's update module expects this to be a database table
  'cache_views'           =>  'default',
  'cache_views_data'      =>  'default',
);

I think it would be great to get some more documentation on this issue. Thanks!

Comments

Comment #0.0

jordanmagnuson commented 2 March 2013 at 08:56

Issue summary:

View changes

Updated issue summary.

Comment #1

erikwebb commented 6 March 2013 at 14:53

cache_form is the only bin that I keep in the database. I've seen other people choose to put cache_bootstrap in APC, but that's a preference not an "advised" setup.

I'm definitely curious if there are others that people move around.

Comment #2

markpavlitski commented 6 June 2013 at 12:21

Status:

Active

» Fixed

cache_form is the only bin that should never be placed into memcache. This is because cache_form is not, strictly speaking, a cache table.

If data is lost from cache_form your site functionality will be affected. This is unlike the other cache tables, where a cache-miss just results in needing to recalculate the data.

See #512026: Move $form_state storage from cache to new state/key-value system for more information and the D8 fix.

Comment #3

20 June 2013 at 12:30

Status:

Fixed

» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Comment #4

jcamposanok commented 18 October 2013 at 16:56

Status:

Closed (fixed)

» Needs review

Sorry to re-open this thread, however I also support the proposal of documenting this matter in a more extensive way. There ARE other bins besides cache_form that may cause issues when assigned to memcache.

For example, one of those bins belongs to contributed module Shorten URLs. "cache_shorten" must be assigned to non-volatile memory (DrupalDatabaseCache) in order to prevent the URL shortening services to be called over and over again, avoiding timeouts or exceeding quota limits.

This kind of information is relevant for users that have both modules at the same time, and therefore should be included either in this module's documentation or the Shorten module docs. Personally I think the best option is to have a single list of non-compatible or conflictive modules included with the Memcache documentation, instead of multiple warnings scattered throughout all the incompatible module docs.

Comment #5

markpavlitski commented 21 October 2013 at 12:58

Category:	support	» task
Status:	Needs review	» Needs work

I'm not convinced that the memcache module is the best place to keep track of this, though maybe we could have an incompatibility page in the community docs on d.o?

Comment #5.0

markpavlitski commented 21 October 2013 at 12:58

Issue summary:

View changes

Updated issue summary.

Comment #6

jeremy commented 18 February 2014 at 01:38

Status:

Needs work

» Closed (won't fix)

It's not going to be possible to maintain a list of all contrib module caches that are not compatible with the memcache module. This information will have to be documented with each given contrib module.

We do already document the known core cache table that should not use memcache.

Comment #7

ryan_courtnage commented 17 June 2014 at 22:13

Commenting on this thread since it's relevant and comes up in search:

My question is, are there other cache bins (potentially provided by contributed modules) that should likewise not be assigned to memcache, or is cache_form unique in this regard?

We've been plagued with random problems of Views defined using exports (ie: from Features) becoming Overridden for no apparent reason. One symptom of this a "Call to a member function set_display() on a non-object" Fatal PHP error being thrown on pages that try to render the a view. Turns out that the "cache_views" table should not be stored in memcache. The problem can rear it's ugly head if an entry for cid=views_default_:en is evicted from memcache.

Comment #8

treksler commented 20 June 2014 at 00:26

@ryan_courtnage did you file a bug with views?

if cache_views can not be truncated, or cleared in memcache, it is broken

Comment #9

les lim

he/they

English

commented 25 January 2015 at 04:05

FWIW, cache_update in D7 core should also not be stored in external caches right now. The update module apparently makes direct db_select calls to the cache_update table at times.