Drupal - Relation entre les champs CCK et les types de contenu à la performance?

Question

J'aide quelqu'un avec une installation de Drupal 6, et ils sont très perturbés par les performances du site, même s'ils sont seulement dans la phase de définition des 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 pris 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 problèmes réels (une certaine lenteur, mais rien de si mauvais). J'ai passé un certain temps cet après-midi à désactiver tous les modules non-core sur le site, et j'ai pu obtenir le temps de chargement de la page de liste des modules à environ 5 secondes. Lorsque j'ai réactivé des groupes de modules, il semble que la famille de modules CCK ait été la plus touchée (augmentation de 15 à 20 secondes du temps de chargement des pages pour la liste des modules).

Encore une fois, j'ai d'autres sites sur ce serveur qui exécutent également CCK (et la plupart des mêmes modules) et ne connaissent rien de tel. 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 suis en train de conclure qu'il existe un lien direct entre les performances du site (au moins pour certaines opérations de création et de modification de types de contenu) et le nombre de types de contenu et de champs personnalisés, mais je n'ai pas pu pour déterminer exactement quel est l'impact de ces types et champs de contenu, et s'il y a quelque chose que vous pouvez faire pour atténuer leur impact. J'ai installé le module Devel, et j'ai trouvé que la plus grande perte de performance sur la page Modules est dans les requêtes concernant cache_menu, mais je ne suis pas sûr que cela soit directement lié au nombre de types de contenu et/ou des champs.

Toutes les indications sont appréciées!

Merci, Paul

Answer 1

Tout d'abord: La page de modules est en effet une bête méchante, comme il évacue complètement toutes les caches internes de Drupal et les reconstructions pour faire en sorte que les modules fraîchement installés ont les données les plus récentes. Ce n'est pas un bon prédicteur des performances du site (puisque seules des tâches administratives spécifiques permettent de vider ces caches), bien que cela soit gênant. Deuxièmement: l'importation des types de contenu vide également ces caches, car CCK veut s'assurer que tout est à jour également. C'est sous-optimal, mais là vous l'avez.

Enfin: Le nombre de champs CCK et de types de contenu que vous avez n'affecte pas 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, construit 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, exacerbant les retards que vous voyez 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 globales du site, juste 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 Views et à la reconstruction dynamique du menu. Chaque fois, le menu est reconstruit, conduisant à 100 ou même 1000 de requêtes. En fonction de la façon dont les jointures sont établies, vous pouvez vous retrouver avec deux jointures similaires, sur les mêmes tables, conduisant à doubler le nombre de requêtes. Plus d'informations peuvent être trouvées here