Performances du site, le cache ne fonctionne pas correctement

J'utilise le module de journalisation des performances . Au-dessus de la capture d'écran, une chose étrange, j'ai remarqué que Insérer Cache_bootstrap sur chaque page. Lorsque vous accédez à n'importe quelle page (à la fois le thème administrateur et le thème frontal), insérer le cache puis supprimer le cache est en cours d'exécution. Cela signifie que le cache est défini et détruit dans chaque page et qu'aucun cache ne se produit réellement. Comment puis-je le développer davantage? Pour diagnostiquer ce problème car je travaille actuellement sur les performances du site.

J'utilise également New Relic pour la vérification des performances. Cela montre également que la charge de la base de données est élevée.

et les informations my.cnf.

La diapositive # 85 de ma présentation des performances parle de la taille maximale des paquets dans MySQL, vous devez augmenter cette valeur; SET GLOBAL max_allowed_packet=33554432;ou modifiez-le à l'intérieur du fichier de configuration https://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html

La taille maximale autorisée des paquets pourrait être l'une des raisons pour lesquelles cela se produit, mais je peux voir plusieurs raisons pour lesquelles il s'agit probablement d'autre chose dans ce cas.

1. Vous n'avez pas seulement des écritures de cache, vous avez également des suppressions de cache explicites. Une écriture de cache échouée entraînerait simplement la répétition des écritures de cache, puis des échecs de cache, mais pas des suppressions.
2. Il s'agit de la table cache_bootstrap. Il existe des caches qui peuvent devenir volumineux, mais ils ne sont généralement pas issus de ce bac.

La raison la plus courante de ce modèle est les appels variable_set () qui se produisent sur chaque page. Jetez un œil à l'origine de ces suppressions de cache, soit avec xhprof, avec xdebug et en définissant un point d'arrêt, soit en ajoutant un debug_print_backtrace (DEBUG_BACKTRACE_NO_ARGS). Je suis sûr que vous y verrez un appel variable_set ().

Le problème est qu'il existe un seul cache global pour les variables. Chaque écriture de cache entraîne une suppression de cache et la prochaine requête lira la {variables}table entière et la réécrira dans le cache.

De nombreux développeurs ne le savent pas et font des choses comme "garantir les valeurs" en appelant variable_set () directement dans un fichier .module ou un autre endroit qui est exécuté à chaque demande.

C'est juste une hypothèse mais si votre cache d'amorçage se reconstruit à chaque chargement de page, il peut arriver que certains de vos modules manquent dans le dossier modules mais toujours présents dans la table système. Sur chaque chargement de page, Drupal essaie de le trouver et de reconstruire bootstrap_cache.

Essayez le module d' optimisation Bootstrap , il vous aidera à trouver de tels enregistrements et à les supprimer.