Separate cache keys per domain [#1570228]

I have set up a sandbox project at http://drupal.org/node/1570130 which allows you to write separate cache keys to the database per domain. I would appreciate it if some of the domain access gurus could cast their eyes over it and let me know if I'm doing anything horribly wrong. Basically I'm creating a new cache backend which extends the DrupalDatabaseCache and prefixes the cache keys with the domain id. There is also a class there for memcache, but I haven't test that out yet. Anyway, I would appreciate any feedback you've got.

Comments

Comment #1

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 10 May 2012 at 19:06

You normally don't need this for the {cache_page} table or the {cache} table. Say more about the use-case here.

Comment #2

mstrelan CreditAttribution: mstrelan commented 10 May 2012 at 21:28

Either cache_views or cache_views_data table is a problem if you use the time-based caching options in views. Also cache_field can be a problem on filtered text fields under certain configurations, for example with Pathologic set to rewrite to absolute URLs - it will cache the domain name of whichever domain was being viewed when the cache was generated.

There's two examples, likely to be more.

Comment #3

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 10 May 2012 at 22:12

Domain CTools may already provide this for Views. The {cache_field} bit makes some sense.

Comment #4

mstrelan CreditAttribution: mstrelan commented 11 May 2012 at 02:07

Domain CTools may already provide this for Views.

I had a quick look at this and it doesn't appear to help, the following from the project page confirms that.

The only feature currently implemented is an access control plugin for Page Manager. This plugin allows you to set domain-specific visibility rules for Pages and Panels.

The specific issue I'm dealing with for Views is a block view showing image thumbnails with different images per domain. The views style plugin is jcarousel (from the jcarousel module) and for one reason or another it can be very slow to load without setting time-based caching on the views results. It is the {cache_views_data} table that stores this cache and either needs to be prefixed per domain or have separate cache keys per domain. The domain_prefix module is not available for D7 and it is too messy trying to prefix the tables in settings.php.

You normally don't need this for the {cache_page} table or the {cache} table.

The module provides an administration page to exclude certain cache bins from being separated. You are right that most tables probably don't need separating - you almost certainly don't want to separate {cache_update} and it is impossible to separate {cache_bootstrap}. I feel that {cache_field} and {cache_views_data} are good enough reasons to use this module.

Comment #5

Alan D. CreditAttribution: Alan D. commented 11 May 2012 at 05:04

Say more about the use-case here

Currently {cache} appears content free.

But to list some generic issues:

Enable a cached global token filter and use [site-name] and you have domain specific content if the rendered content is stored, {cache_filter} and ???.

We have entity specific titles per domain - same node, different titles. We were getting the titles cached as these are set during entity_load(). As a result, we can not trust anything per domain, so if it has content, we have to assume that somewhere there is domain specific info.

Metatags was caching the wrong HTML page domain titles, although we never tracked this down - a simple template preprocess HTML fixed that one though.

Another modification allows block domain titles, another potential issue.

Basically, it is a huge and complex collection of sites, and we simply do not trust any content that is stored. Thus if it is a content cache, we are looking at caching per domain. We would rather a bloated database than an unhappy client.

Comment #6

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard commented 11 May 2012 at 14:14

Makes sense to me, thanks for the background.

Comment #7

DamienMcKenna

NH, USA

CreditAttribution: DamienMcKenna commented 14 October 2012 at 02:45

So is the problem that you can't change the cache tables per domain, or that you want a more generic solution that would work regardless of the caching backend (database, memcache, etc)?

Comment #8

mstrelan CreditAttribution: mstrelan commented 14 October 2012 at 23:03

@DamienMcKenna - it would be equally suitable to prefix the cache tables in settings.php but I'm not sure how easy that is to do with DA, particularly automatically when adding / modifying domains.