Drupal - Relation entre les champs CCK et les types de contenu et les performances?

Question

J'aide quelqu'un avec une installation de Drupal 6 et celui-ci est très angoissé par les performances du site, même s'il ne fait que définir ses types de contenu. Le chargement de la liste des modules peut prendre plus de 30 secondes et l'importation d'un type de contenu a nécessité près de 3 minutes.

Ceci est installé sur un grand système UNIX partagé et j’exécute d’autres installations D6 sur le même serveur sans aucun problème réel (quelques lenteurs, mais rien de si grave). Cet après-midi, j'ai passé du temps à désactiver tous les modules non essentiels du site et j'ai pu réduire le temps de chargement de la page de liste des modules à environ 5 secondes. Lors de la réactivation de groupes de modules, il a semblé que celui qui avait le plus souffert des performances était la famille de modules CCK (augmentation du temps de chargement des pages de 15 à 20 secondes pour la liste des modules).

Encore une fois, sur ce serveur, d’autres sites exécutent également CCK (et la plupart des mêmes modules) et ne rencontrent rien de ce genre. La principale différence est que ce site très lent a une tonne de types de contenu et de champs CCK définis - 46 types de contenu distincts et 162 champs CCK.

Je conclus qu'il existe un lien direct entre les performances du site (du moins dans certaines opérations liées à la création et la modification de types de contenu) et le nombre de types de contenu et de champs personnalisés, mais je n'ai pas pu Déterminez exactement quel est l'impact de ces types de contenu et de ces champs et si vous pouvez faire quelque chose pour les atténuer.

J'ai installé le module Devel et constaté que les performances de la page Modules se trouvaient principalement affectées par les requêtes relatives à cache_menu, mais je ne suis pas sûr que cela soit directement lié au nombre de types de contenu et / ou champs.

Toute orientation est appréciée!

Merci, Paul

Answer 1

Tout d'abord: la page des modules est en effet une bête féroce, car elle vide complètement tous les caches internes de Drupal et les reconstruit pour garantir que les modules récemment installés disposent des données les plus récentes. Ce n'est pas un bon prédicteur des performances du site (car généralement, seules des tâches administratives spécifiques effacent ces types de caches), bien que cela soit gênant.

Deuxièmement: Importer des types de contenu vider AUSSI ces caches, car CCK veut s’assurer que tout est également à jour. C'est sous-optimal, mais voilà.

Enfin: le nombre de champs CCK et de types de contenu dont vous disposez influe sur la quantité de travail effectuée lorsque les caches sont vidés et reconstruits. CCK récupère toutes les informations sur tous les types de contenu définis et leurs champs, crée une structure de données pour les décrire tous et utilise cette version mise en cache pour référence ultérieure. Avec des centaines de champs et des dizaines de types de contenu, la reconstruction de ce cache de données prend plus de temps, ce qui accentue les retards constatés sur la page des modules et lors de l'importation de nouveaux types de contenu.

La bonne nouvelle (telle qu’elle est) est que ce problème particulier n’a pas trop d’impact sur les performances générales du site, mais uniquement sur les actions administratives qui vident ces caches.

Answer 2

C’est la même réponse que j’ai faite sur une autre question Drupal; Si la réponse d'Eaton ne résout pas votre problème, vous devriez peut-être jeter un coup d'œil au module Vues et à la reconstruction dynamique du menu. Chaque fois, le menu est reconstitué, ce qui entraîne des centaines voire des milliers de requêtes. En fonction de la manière dont les jointures sont effectuées, vous pouvez vous retrouver avec deux jointures similaires, sur les mêmes tables, conduisant à un doublement du nombre de requêtes. Plus d'informations peuvent être trouvées ici