Problem/Motivation

In #2765271: Rationalize use of the 'discovery' cache bin, since it's stored in the limited size APCu by default, we're rationalizing the use of the discovery cache bin.

We already landed #2824547: Change ViewsData to use the default cache bin instead of discovery and #2824548: Move token info cache to data cache bin as part of that. That really helps, see #2765271-19: Rationalize use of the 'discovery' cache bin, since it's stored in the limited size APCu by default.

But, multilingual sites face a bigger problem: multilingual (translated) configuration. (@dawehner already mentioned this in the issue summary of #2800605: Warn/inform users when the hosting environment has a too low limit of APCU cache.) Because

  config.typed:
    class: Drupal\Core\Config\TypedConfigManager
    arguments: ['@config.storage', '@config.storage.schema', '@cache.discovery', '@module_handler']

means that all translated configuration is also cached in the discovery bin. So, the more multilingual you are, the bigger of a problem you have.

This can easily result in a few megabytes per language … meaning that you can reach the APCu limit rather quickly.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

Wim Leers created an issue. See original summary.

Wim Leers’s picture

Berdir’s picture

Uhm, no? :)

That is the config schema plugin manager. It has the config schema definitions, not actual config.

Yes, translated config is in apcu, like all other config too, but as part of the config cache bin?

Gábor Hojtsy’s picture

Right, if we are concerned for multilingual config, then this snippet in the issue summary is not correct, that does indeed involve the schema:

  config.typed:
    class: Drupal\Core\Config\TypedConfigManager
    arguments: ['@config.storage', '@config.storage.schema', '@cache.discovery', '@module_handler']

Unless of course we cache it translated(?) -- but I doubt that.

Berdir’s picture

Status: Active » Postponed (maintainer needs more info)
stella’s picture

I can confirm that we've started getting APCu cache limit problems as soon as we started adding in multilingual content and config. So much so that the errors filled up our log files and we ran out of space. Thankfully not live yet!

stella’s picture

Oh and by the way, we will have 13 languages in total (including en-us, en-gb, etc), so this is a big issue for us. More than happy to test patches or do whatever I can to help on this.

Berdir’s picture

@stella:

Right.. but your problem isn't going to be the config *schema* cache.. if anything it's going to be the actual config translations.

Berdir’s picture

Title: Multilingual config cached in "discovery" cache bin; quickly reaches APCu memory limits » Multilingual config cached in "config" cache bin; quickly reaches APCu memory limits
Status: Postponed (maintainer needs more info) » Active

Updating title based on how understand this, has nothing to do with discovery cache bin but with config. Still needs an issue summary update.

Also discussed with @stella in IRC. The default of having config in fast chained in config makes sense for no multlingual, it probably still makes sense for 1-2 additional languages.. for 13 languages, probably not :)

As a workaround, don't put it in fast chained: $settings['cache']['bins']['config'] = 'cache.backend.database'; (or redis, or memcache)

I'm not sure what we can do about this in core. I don't like not putting it in fast chained, I don't like not caching non-default collections although it might not make a big difference at least when using database backend.

effulgentsia’s picture

Not sure if it's a good idea or feasible, but maybe allowing something in $settings (or services.yml) to specify different cache backends for different config collections?

effulgentsia’s picture

Or similarly, for config collections to be assignable to a different cache bin?

Berdir’s picture

Maybe, but if you do have a multilingual, then every config load will always also have to check for the existense of a language override, so you'll have just as many config reads for collection as not.

Hm.. I guess there is a pretty large percentage of configs that do *not* exist in language collections. Maybe we could cache non-existing config in a single global blacklist-cache instead of creating hundreds of cache entries that just contain FALSE as we do right now?

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

anavarre’s picture

Is there any hope to get this in 8.3.x or at this point should we directly move to 8.4.x?

Gábor Hojtsy’s picture

Category: Task » Bug report

As per https://www.drupal.org/core/d8-allowed-changes#beta among things allowed in beta are bug fixes and contributed project blockers, if they are non-disruptive, or if the impact outweighs the disruption. I would argue if the APC limits are reached this is a bug not a task. Then its up to committers to asses the disruption vs. impact. I think a patch if possible would help asses that.