←Retour au blog

Accélérez le backend Drupal avec $settings['state_cache']

2025-08-13•6 min de lecture

Sur un grand site Gov Drupal sur lequel je travaille, /admin/reports/status et /admin/config étaient lents. Après avoir activé $settings['state_cache'], les pages se sont chargées beaucoup plus rapidement. Les éditeurs l'ont remarqué immédiatement.

Si votre zone d'administration vous semble lente, cela pourrait aider. Drupal effectue de nombreuses petites lectures de l'API State par requête, et leur mise en cache réduit les accès à la base de données. Dans Drupal 10.3, vous pouvez l'activer avec $settings['state_cache'] = TRUE dans settings.php. Dans Drupal 11, la mise en cache de l'état est toujours activée et le réglage a été supprimé. Si votre site stocke un grand nombre d'éléments volumineux dans State, examinez-les d'abord avant de l'activer en 10.3.

Ce que stocke l'API State

Drupal conserve de petites valeurs spécifiques au site dans une collection clé-valeur nommée state. Exemples : dernière exécution de cron, indicateurs de maintenance, bascules d'aide utilisées par le cœur et les modules. Sans mise en cache, chaque lecture peut accéder à la base de données.

Pourquoi state_cache aide

Les écrans d'administration effectuent de nombreuses petites vérifications. La mise en cache de ces valeurs supprime de nombreux appels à la base de données. Le résultat est des pages plus rapides et une charge de base de données réduite. Changement simple, gain évident.

Disponibilité

  • Drupal 10.3+ : optez pour $settings['state_cache'].
  • Drupal 11+ : activé par défaut ; le réglage a été supprimé.

Comment ça marche

Drupal charge une valeur une fois, la stocke en cache et la réutilise lors des requêtes ultérieures. Lorsqu'une valeur change, Drupal met à jour le stockage et invalide l'entrée de cache. Les lectures restent rapides et les données restent correctes.

Activer dans Drupal 10.3+

Ajoutez ceci à settings.php :

$settings['state_cache'] = TRUE;

Puis videz les caches.

Vérification rapide avant d'activer

Si votre site conserve trop de valeurs ou des valeurs trop volumineuses dans state, leur mise en cache peut gaspiller de la mémoire. Exécutez cette requête :

SELECT COUNT(*) AS num_items,
       SUM(LENGTH(value)) AS total_bytes
FROM key_value
WHERE collection = 'state';

Vous pouvez exécuter la même chose avec Drush :

drush sql:query "SELECT COUNT(*) AS num_items, SUM(LENGTH(value)) AS total_bytes FROM key_value WHERE collection = 'state';"

PostgreSQL :

drush sql:query "SELECT COUNT(*) AS num_items, SUM(OCTET_LENGTH(value)) AS total_bytes FROM key_value WHERE collection = 'state';"

Règles générales :

  • num_items jusqu'à environ 100 et total_bytes autour de 100 Ko, c'est généralement bon.
  • Si vous voyez de gros blobs, déplacez-les ailleurs (un bac à cache, la configuration ou une table personnalisée) avant de l'activer.

Problèmes que cela peut atténuer

  • Pages d'administration lentes après la connexion.
  • Charge élevée de la base de données pendant le travail éditorial, les traitements par lots ou une utilisation intensive de cron.
  • Pics de latence sur les serveurs de base de données partagés.

Si votre backend de cache est la base de données

Oui, cela aide toujours. Vous effectuerez moins de lectures depuis key_value. Les pages d'administration peuvent se charger plus rapidement. Mais les lectures accèdent toujours à la base de données, donc les gains sont moindres qu'avec Redis ou Memcached. Il est sûr de l'activer maintenant et de prévoir un passage à un cache en mémoire plus tard.

Bonnes associations

  • Redis ou Memcached pour le stockage du cache afin que les accès à l'état résident en mémoire. Vérifiez votre backend de cache dans settings.php et surveillez les taux de succès.
  • Gardez l'état léger. Utilisez-le pour les indicateurs et les valeurs légères, pas pour les gros blobs.
  • Mesurez avant et après. Localement, essayez Webprofiler ou Devel pour comparer le nombre de requêtes. En production, utilisez votre APM.

Mises en garde

  • Des valeurs d'état très volumineuses peuvent gonfler le cache. Corrigez les données d'abord, puis activez.
  • Les vidages de cache ne suppriment pas les valeurs d'état ; ils invalident seulement les copies mises en cache.
  • Sur Drupal 11, il n'y a rien à configurer. Vous bénéficiez déjà du gain.

Liste de contrôle rapide

  1. Exécutez la vérification SQL ci-dessus.
  2. Supprimez les valeurs surdimensionnées de state.
  3. Sur Drupal 10.3 à 10.x, ajoutez $settings['state_cache'] = TRUE; et videz les caches.
  4. Confirmez moins de requêtes sur les pages d'administration et observez la baisse de la charge de la base de données.

En résumé

Petit changement. Amélioration notable pour les éditeurs. Activez-le, testez et profitez de pages d'administration plus réactives.

Catégories:

DrupalPerformance