Domain conf module registers shutdown function that sets stored language_default variable on each Drupal shutdown.
This way, drupal has to drop variables cache in cache_bootstrap table and recreate it on next request, after which the cache also will be flushed.

Hence, Drupal not only loses 20% effectivity (see variable_initialize: NOTE: caching the variables improves performance by 20% when serving cached pages.), but also wastes time to recreate this unused cache.
Also, with high loads and when drupal is forced to recreate variables cache on each request InnoDB falls to deadlock state:

PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: DELETE FROM {semaphore} 
WHERE  (name = :db_condition_placeholder_0) AND (value = :db_condition_placeholder_1) ; Array
(
    [:db_condition_placeholder_0] => variable_init
    [:db_condition_placeholder_1] => 98291012950c63acdeaf731.88652064
)
CommentFileSizeAuthor
#4 domain-remove-js-alter-1865552-4.patch438 bytesBerdir
#1 1865552_domain_conf_variable_set_only_when_necessary.patch1.02 KBSergii
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sergii’s picture

Sergii CreditAttribution: Sergii commented
Status: Active » Needs review
FileSize
1865552_domain_conf_variable_set_only_when_necessary.patch1.02 KB

Patch supplied

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
CreditAttribution: agentrickard commented
Status: Needs review » Needs work

This was a nasty problem to fix in the first place. See #1271810: Default language gets changed for the original background.

I understand what the patch is doing. However, doesn't this result in having stale variables in the cache?

This code should only run in specific cases. Not on every page. So the problem really seems to be hook_js_alter().

/**
 * Implements hook_js_alter().
 */
function domain_conf_js_alter(&$javascript) {
  domain_conf_js_maintain();
}

What happens if we simply remove that call?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
CreditAttribution: agentrickard commented

I thought about this some more. I don't think we have to worry about stale cache. The original fix is to ensure that the initial (cached) value is retained in {variable}.

So my question is: Can we solve the issue by removing hook_js_alter()?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
CreditAttribution: agentrickard commented
Issue summary: View changes

spelling

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir at MD Systems GmbH commented
Issue summary: View changes
Status: Needs work » Needs review
FileSize
domain-remove-js-alter-1865552-4.patch438 bytes

Blast from the past :)

This patch does what #3 suggests, by removing that alter hook. I didn't test yet if it causes any problems, doing that as a set of performance improvements on a site that I will give to the client for testing soon.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
CreditAttribution: agentrickard at Palantir.net commented

We may also need to check that the variable is in fact changing in this code:

/**
 * Shutdown function to reset the default language variable.
 *
 * @param $default_language
 *  A language object, stored by domain_conf_default_language().
 */
function domain_conf_set_default_language($default_language) {
  if (!empty($default_language) && is_object($default_language)) {
    variable_set('language_default', $default_language);
  }
}