[Résolu] Perte de performance

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by emena on

Bonjour,

J'ai depuis quelque temps, un problème majeur de performance. Il est apparu quand j'ai créé quelques champs supplémentaires (5/15) pour un de mes types.

La base de données à doublée de taille, mais se sont essentiellement des flux agrégés. J'ai vérifié mes backups. Rien de très inquiétant de ce côté-là. J'ai rajouté 512 mégas de RAM, ça n'a eu aucun effet.

J’ai mis devel et debug for firebug, j'ai quelques informations. Malheureusement, cela ne me dit pas grand-chose, à part que j'ai des accès DB trop longs et pas assez de mémoire.

Je vous en donne le début, si quelqu'un a une idée
Merci d'avance
EM

Fatal error: Out of memory (allocated 54788096) (tried to allocate 524389 bytes) in /srv/.../htdocs/includes/cache.inc on line 105
Executed 90 queries in 1341.98 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 2804.53 ms.
ms
#
where
query
360.17
1
content_field_instance_read
SELECT * FROM ctr_content_node_field_instance nfi JOIN ctr_content_node_field nf ON nfi.field_name = nf.field_name WHERE nfi.type_name = 'multimedia' AND nf.active = 1 AND nfi.widget_active = 1 ORDER BY nfi.weight ASC, nfi.label ASC
258.85
1
content_field_instance_read
SELECT * FROM ctr_content_node_field_instance nfi JOIN ctr_content_node_field nf ON nfi.field_name = nf.field_name WHERE nfi.type_name = 'fiche_recettes' AND nf.active = 1 AND nfi.widget_active = 1 ORDER BY nfi.weight ASC, nfi.label

ASC
123.79
1
content_field_instance_read
SELECT * FROM ctr_content_node_field_instance nfi JOIN ctr_content_node_field nf ON nfi.field_name = nf.field_name WHERE nfi.type_name = 'fiche_divers' AND nf.active = 1 AND nfi.widget_active = 1 ORDER BY nfi.weight ASC, nfi.label

ASC
118.79
1
content_field_instance_read
SELECT * FROM ctr_content_node_field_instance nfi JOIN ctr_content_node_field nf ON nfi.field_name = nf.field_name WHERE nfi.type_name = 'simplenews' AND nf.active = 1 AND nfi.widget_active = 1 ORDER BY nfi.weight ASC, nfi.label ASC
103.47
1
node_load
SELECT n.nid, n.type, n.language, n.uid, n.status, n.created, n.changed, n.comment, n.promote, n.moderate, n.sticky, n.tnid, n.translate, r.vid, r.uid AS revision_uid, r.title, r.body, r.teaser, r.log, r.timestamp AS revision_timestamp, r.format, u.name,

u.picture, u.data FROM ctr_node n INNER JOIN ctr_users u ON u.uid = n.uid INNER JOIN ctr_node_revisions r ON r.vid = n.vid WHERE n.nid = '161'
81.32
1
taxonomy_node_get_terms
SELECT t.* FROM ctr_term_node r INNER JOIN ctr_term_data t ON r.tid = t.tid INNER JOIN ctr_vocabulary v ON t.vid = v.vid WHERE r.vid = 163 ORDER BY v.weight, t.weight, t.name
45.73
1
drupal_lookup_path
SELECT dst FROM ctr_url_alias WHERE src = 'node/161' AND language IN('fr', '') ORDER BY language DESC, pid DESC
39.69
1
sess_write
UPDATE ctr_sessions SET uid = 6, cache = 1297104314, hostname = '109.128.27.15', session = 'messages|a:1:{s:5:"error";a:1:{i:0;s:108:"APC is not enabled. It is <strong>not</strong> safe to enable summary logging to the database on live

sites.";}}', timestamp = 1297105254 WHERE sid = '77cccaf1325a84541424ecf471b58838'
38.17
1
taxonomy_get_vocabularies
SELECT v.vid, v.*, n.type FROM ctr_vocabulary v LEFT JOIN ctr_vocabulary_node_types n ON v.vid = n.vid WHERE n.type = 'recettes_2011' ORDER BY v.weight, v.name
37.8
1
image_get_random
SELECT DISTINCT(n.nid), RAND() AS rand FROM ctr_node n WHERE n.type = 'image' AND n.status = 1 ORDER BY rand LIMIT 0, 1
37.3
0
locale
SELECT s.lid, t.translation, s.version FROM ctr_locales_source s LEFT JOIN ctr_locales_target t ON s.lid = t.lid AND t.language = 'fr' WHERE s.source = ' Queries taking longer than @threshold ms and queries executed more than once, are <span

class="marker">highlighted</span>.' AND s.textgroup = 'default'
32.9
1

Forum : 
Développement
Version de Drupal : 
6.x
Tags : 
performance

Soumis par emena le 8 Février, 2011 - 13:21

Hello,

Je continue mes investigations, les plus gros temps d'accès DB les recherches de champs, avec des JOIN. J'ai 15 champs, et 25 instances aux total, cela ne me parait pas si gros.

J'ai un cache php, mais pas de "cache APC" me dit devel. Je n'ai pas trouvé s'il y en a chez mon hébergeur, je cherche.

SI quelqu'un a un expérience GANDI, elle est la bienvenue.

EM

Soumis par vincent59 le 8 Février, 2011 - 14:48

Généralement le cache APC n'est pas dispo sur du mutualisé.
Si tu as un hébergement dédié, il est possible d'en installer un, mais ça ne va pas améliorer les performances côté base de données, qui reste le point faible de Drupal...

quand on voit le nombre de requêtes SQL qu'une simple page balance (une petite centaine), on se dit que le serveur de base doit être bien configuré.

Si tu as accès au paramétrage MySQL, il y a pas mal de gains de ce côté là, mais tout dépend encore de ton hébergement : dédié ou mutualisé.

Soumis par emena le 8 Février, 2011 - 17:10

Merci de me répondre, enfin une piste.

C'est un serveur virtuel, presque du dédié sauf que je n'ose pas tout faire, je n'avais plus fait vraiment d'informatique depuis le SERIE 1 d'IBM.

Je suis rassurée de voir que le nombre de requêtes ne te parait pas absurdes.

Comment savoir ce que je peux paramettrer dans MySql, as-tu des tuto, des pistes ? je t'avoue que je n'y connais rien de côté là, mais je suis prète à m'y mettre.

J'ai déjà compacté, pour récupérer les places des nodes supprimés. L'effet n'a pas été visible.

EM

Soumis par vincent59 le 8 Février, 2011 - 22:44

OK, bonne nouvelle si c'est du virtuel, tu devrais avoir plus de latitude.

Côté consommation RAM, dans Devel on peut demander d'afficher la mémoire utilisée (admin/settings/devel, show memory usage). Tout en bas des pages, Drupal affiche la mémoire avant et après la page.

Chez moi par exemple, c'est 1.4 Mb avant et 12,6 MB après. Sur une page d'admin j'ai 120 requêtes...
Sur une page "normale", c'est toujours entre 80 et 100 (et pas beaucoup de modules activés).

Pour la partie base de données, il faut aller voir du côté du fichier my.cnf (/etc/mysql/my.cnf ou /etc/my.cnf ça dépend de la distrib).
Par défaut ce n'est souvent pas optimal. Si tu as accès à un shell linux, le script tuning-primer.sh donne pas mal d'indications (cf. http://www.geeek.org/post/2009/02/11/Optimisation-MySQL-%3A-Une-solution...).

Il faudrait que je fouille un peu mes archives, j'ai fait de l'optimisation de perfs drupal.

Sinon, tu peux essayer avec Pressflow, c'est une distribution Drupal 100% compatible, optimisée pour les performances et PHP 5.

Une fois résolu les problème MySQL on pourra attaquer APC. Et là ça dépote souvent...

Soumis par emena le 9 Février, 2011 - 15:46

Hello,

Un petit mot entre-deux, je n'aurais pas beaucoup de temps aujourd'hui.
Il rame moins quand je suis déconnectée, mais il reste très lent.

J'ai un premier résultat :

Page d'acceuil
Page execution time was 17060.23 ms.
Memory usage: Memory used at: devel_init()=0.74 MB, devel_shutdown()=119.7 MB.

Un node avec 2 photos et 3 commentaires
Page execution time was 16509.41 ms.
Memory usage: Memory used at: devel_init()=0.74 MB, devel_shutdown()=117.13 MB.

Une selection via taxonomy
Page execution time was 35205.63 ms.
Memory usage: Memory used at: devel_init()=0.74 MB, devel_shutdown()=116.15 MB.

Admin/type/champs
Fatal error: Maximum execution time of 30 seconds exceeded in /srv/d_amh-ct/www/adm.testct.be/htdocs/sites/all/modules/contrib/Formatage contenu/cck/includes/content.crud.inc on line 504
Page execution time was 33251.86 ms.
Memory usage: Memory used at: devel_init()=0.74 MB, devel_shutdown()=116.41 MB.

Module Biblio que je craignais
Page execution time was 19151.88 ms.
Memory usage: Memory used at: devel_init()=0.74 MB, devel_shutdown()=117.51 MB.

En conclusion très provisoire

  • En terme de taille : mes pages sont un peu grosses, je ne sais pas encore pourquoi.
  • En terme de temps : j'utilise « Taxonomy Term Permissions », avec 4 règle par rôle, qui doit sans doute être gourmand. J'ai (un tout petit peu) amélioré les choses en diminuant le nombre de rôles, ce qui semble confirmer qu'il y a un gain possible ici.. Le tout est de trouver une solution qui ne me fasse pas ralentir encore plus ?
  • Je vais suivre les pistes proposées que je n'ai pas encore explorées.

Soumis par vincent59 le 9 Février, 2011 - 17:56

Les messages d'erreur (Maxmimum execution time et failed to allocated...) sont liés au paramétrage PHP, dans le fichier php.ini

Il faudrait augmenter ces valeurs, par exemple, dans la partie Resource Limits :

max_execution_time = 600     ; Maximum execution time of each script, in seconds
max_input_time = 60  ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 128M

Par contre, c'est vrai que 100 MB utilisé à chaque page par Drupal, ça me paraît beaucoup... fort beaucoup, même ;-)

Ce serait intéressant de faire les tests en désactivant certains modules, afin de voir l'impact de chacun.

Soumis par emena le 9 Février, 2011 - 22:46

Hello,

merci vincent59, j’ai maintenant une piste sérieuse.
J'ai désactivé les modules les uns après les autres, c'est imagefied qui pose le problème.
Si je le désactive je passe, pour la page d'accueil à :

Page execution time was 434.19 ms.
Memory usage: Memory used at: devel_init()=0.74 MB, devel_shutdown()=5.68 MB.

Rien de comparable, mais à quoi est-ce du ?

  • Est-il possible que la taille de mes photos, à laquelle je n'ai pas du tout fait attention intervienne.
  • Quel dpi vous paraît le minimum correct ?
  • Est-ce encore trop de Méga pour une page d'accueil ?

J’arrive maintenant à accéder à toutes mes pages y compris celle de l'administration. Mais je me demande

  • comment la suppression de champs CCK dans mes nodes peut-elle avoir une influence sur les pages d'administration qui ont tout autant diminué.

Bref, bonne nuit et à demain.

Soumis par emena le 10 Février, 2011 - 09:01

En vitesse, avant de partir au travail,

J'ai fait rapidement quelques tests.

  • Une de mes hypothèses était que Drupal faisait un « buffer image » par type de page. Comme j'ai une image par type et 10 types, cela aurait pu devenir beaucoup. Ce n'est pas le cas, je n'ai pas d'accroissement de la taille des pages quand j'accrois le nombre de type avec images.
  • J'ai varié la taille des images, pour voir si cela influençait la taille de la page, ce n'est pas le cas apparemment.

Cela m'étonnait aussi de Drupal, et puis, comment rue89 aurait-il pu tourner avec ce type d'approche.
Bref, je n'ai pas trouvé pourquoi ce module me donne une page de 100M.

Bonne journée

EM

Soumis par vincent59 le 10 Février, 2011 - 09:56

J'imagine que tu utilises ImageCache en plus d'imageField.

Il faudrait peut-être vérifier également le paramétrage de l'affichage de ces champs, en mode teaser et full : vignette, original ? A mon avis cela peut jouer.

Mais la différence est effectivement impressionnante.

Pour les pages d'admin, elles sont toujours beaucoup plus longues & lourdes, Drupal charge plein de trucs

Soumis par emena le 10 Février, 2011 - 12:31

Hello,

Avec ou sans image cache, cela ne fait pas de différences majeures. Mais je prendrais le temps d'affiner cela ce soir, mes paramétrages sont peut-être mal faits.

Par contre, à propos des pages admin, je ne comprends pas.

  • Pages Normales
    • imagefield actif -> Pages site environ 116M
    • imagefield inactif -> Pages site environ 6M
  • Pages admin
    • imagefield actif -> Pages admin environ 120M
    • imagefield inactif -> Pages admin environ entre 7M et 20M

Je pensais pas que le fait de desactiver imagfield n'aurait pas d'effet sur elles, or cela en a et beaucoup. J'ai l'impression que quelque chose ne va pas avec imagefiel dans mon installation. Une incompatibilité, une erreur de paramétrage ?

EM

Soumis par emena le 14 Février, 2011 - 09:26

Bonjour,

Le point sur mes recherches :

J’ai augmenté la taille de ma mémoire et des timout, comme tu me l’avais suggéré vincent59 :

max_execution_time = 600 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
max_input_nesting_level = 128 ; Maximum input variable nesting level memory_limit = 128M

Pour les utilisateurs anonymes, la différence est tout à fait perceptible, pour les identifiés, ce n’est pas le cas. J’ai les mêmes délais. Ce qui me semble être l’indice que j’ai maintenant assez de mémoire pour le cache mais que je garde des problèmes, soit de nombre d’accès DB, soit d’autre chose.

Je n’utilise pas vraiment imageCache, je préfère préparer moi même mes photos en local, elles sont moins déformées. Il ne me sert plus vraiment, je l'ai enlevé sans effet. J’ai supprimé la seule de mes vraiment grosse photo. Les autres restent en deçà de 350k. Je descendrais encore dans l’avenir, mais il ne semble pas que cela ai de l’influence.

Avant d’attaquer un changement de distribution et d’essayer Pressflow, j’aimerais comprendre pourquoi ces 100M. Je reste avec le sentiment d'un couac, de quelque chose qui ne va pas. Je me demande si je ne vais pas supprimer le type incriminé et le recréer. Il n’y aurait environ 20 nodes à restaurer, cela vaut peut-être la peine d'essayer. Je préfère optimiser avec une base de donnée dont je suis sure qu'elle est cohérente.

Je vous tiendrais au courant quand j’aurais la solution.

Merci de vos suggestions.

EM

Soumis par vincent59 le 14 Février, 2011 - 10:01

Un truc à essayer avant d'aller plus loin : désinstaller puis réinstaller imagefield, on ne sait jamais.

imageCache peut être intéressant si tu veux générer à la volée des vignettes (avec la fonctions Scale) ou des images de différentes tailles.

Soumis par sahuni le 14 Février, 2011 - 11:02

Oui, moi je supprimerai le type incriminé, surtout que tu as dis dans l'autre poste, que ton module spécial n'avait pas créé une nouvelle table, c'est donc que les champs se trouvent dans la table content_type_tontype.

Soumis par emena le 15 Février, 2011 - 22:49

Hello,

J'ai tenté de réinstaller imagefield comme si c'était une nouvelle version, avec update... cela n'a pas eu d'effet. Dommage, j'aurais bien aimé.

J'ai supprimé le type qui avait eu un problème :

    * Pages normales
          o Avant -> Pages site environ 116M
          o Après -> Pages site environ 53M
    * Pages admin
          o Avant -> Pages admin environ 120M
          o Après -> Pages admin environ entre 60M
    * Les différences de temps de réponse sont encore plus marquantes.
          o Avant -> 30 à 50 s
          o Après -> entre 1s et 5s, en mode connectée.

Mes pages restent grosses, mais j'ai beaucoup de photos. C'est peut-être normal, c'est encore à creuser.
En tout cas, les temps de réaction redeviennent comme avant l'introduction de ces champs CCK.

Merci encore
EM

Soumis par emena le 16 Février, 2011 - 11:49

Hello,

J'ai continué mes investigations et mes nettoyages, je garde en vue la taille de tes pages Vincent.
Dans mon site :

  • un nouveau type (sans champs CCK) cela augmente la taille de mes pages de 3M
  • un nouveau champ image , l'augmente de 3M, même si la taille de mes images est limitée à 2M. Se limite la taille de mes images à 350k, la taille allouée diminue, logique.
  • Si j'enlève les champs multimédias, je gagne 20M

    Ma page d'accueil est donc passée de 116M à 42M, c'est déjà ça !

    EM

    Soumis par emena le 19 Février, 2011 - 18:25

    Hello,

    j'ai fais beaucoup de tests. Je n'ai pas réussi à reproduire exactement ce qui s'était passé, mais la taille actuelle est cohérente avec les besoins de CCK et mes performances correctes.

    Merci de votre aide

    EM

    Soumis par vincent59 le 20 Février, 2011 - 21:20

    C'est quand même bizarre les valeurs que tu donnes.

    Quand je fais des tests, je reste toujours dans les mêmes valeurs...
    De base : 12.17 MB
    Après ajout d'un type de contenu sans champ CCK : 12.19 MB
    Après ajout d'un champ image dans le nouveau type : 12.23 MB

    C'est vrai que je n'ai pas beaucoup de modules activés, mais je n'ai pas de bond de 10MB...

    Soumis par emena le 20 Février, 2011 - 22:26

    Hello,

    J'ai fait la liste de ce qui est actif, il y en a plus que je ne le pensais, mais je ne vois rien. J'ai beau débrancher un à un tout ce qui me paraît douteux, je ne trouve plus d'effet visible. Si tu as l'occasion de jeter un coup d'oeil, peut-être que quelque chose te sautera aux yeux.

    Backup and Migrate
    Site User List 6.x-1.1-beta2
    Protect Critical Users 6.x-1.1
    CSS Injector
    Pathauto 6.x-1.5
    Poormanscron 6.x-1.1
    Scheduler 6.x-1.8

    Nodewords 6.x-1.11,
    XML sitemap 6.x-1.2
    Devel 6.x-1.23
    CAPTCHA 6.x-2.4

    Content Construction Kit (CCK)
    Save & Edit
    CCK Teaser Field 6.x-1.0-beta1
    BUEditor 6.x-2.2
    Date 6.x-2.7
    Link 6.x-2.9
    Printer, e-mail and PDF versions 6.x-1.12

    IMCE 6.x-1.4
    FileField 6.x-3.9
    ImageField
    Image
    Lightbox2 6.x-1.11

    Bibliography Module 6.x-1.15

    Simplenews 6.x-1.3
    Simplenews Roles 6.x-0.1
    Mime Mail 6.x-1.0 alpha7

    Tagadelic 6.x-1.2
    Taxonomy Access Control 6.x-1.3
    Taxonomy Defaults 6.x-2.1
    Taxonomy Term Permissions 6.x-1.0
    Token 6.x-1.15

    Merci 1000 fois de ton aide.
    EM