temps SQL anormal... ?

samedi 7 mars 2009 à 23h50
par pamillet

Logo de pamillet

bonsoir,

j’essaie d’analyser les causes de temps de réponse mauvais, sachant que j’ai tout changé
– herbergeur (pour ovh)
– spip (de 1.9 à 2.0.5)
– de squelette pour sarka

Quand je regarde en debug, je m’aperçois qu’une requete de la boucle article date met presque toujours entre 8 et 15s.. ce qui fait beaucoup sur une base de 32 articles...

est ce que ce pb est général ?
comment identifier la cause, sachant que dans mon ovhplan, je n’ai pas accès à un outil de monitoring sql... ?

voilà le debug (dans mon cas, les articles ne sont pas numérotés)

plugins/auto/sarkaspip_3/noisettes/rubrique/inc_rubrique_articles.html : squelette résultat code calcul Temps de calcul : 8.980s
#ENV
id_rubrique  : 4
lang  : fr
1 boucle résultat code calcul
2 boucle résultat code calcul
3 boucle résultat code calcul

merci d’avance des bonnes idées....

pam


Ce sujet est verrouillé : vous pouvez consulter son fil de discussion mais vous ne pouvez plus y répondre.

Réponses

8 mars 2009 à 11h32
_Eric_

Logo de _Eric_

Salut Pamillet,

Oui c’est intéressant ta remarque. En l’occurrence c’est un problème de la boucle Sarka-SPIP à mon avis. C’est cette fameuse boucle compliquée qui a l’énorme avantage de traiter rubrique par rubrique le fait qu’on utilise la numérotation des articles ou l’ordre chronologique inverse.
L’alternative serait de choisir par config le tri des articles mais cela s’appliquerait alors à toutes les rubriques. Remarque je pense que c’est suffisant.

Aussi, peux tu me dire quelle tri tu utilises (date ou numéro) et j’enverrais un fichier modifié pour que tu me dises si ça résoud le problème. Merci d’avance.

Il y a aussi une autre noisette qui pose problème quand on à beaucoup d’articles c’est celles des derniers commentaires. J’ai proposé un patch pour un utilisateur mais j’en suis pas encore satisfait car il ne donne pas rigoureusement le même résultat dans tous les cas.
8 mars 2009 à 12h40
pamillet

Logo de pamillet

salut,

j’utilise un tri par date, pas de numéro dans les titres..

j’avoue d’ailleurs que ce truc spip des numéros dans le titre ne me parait pas génial... ça me rappelle de vieux souvenir quand c’était difficile de gérer des indexs... Bon, celà dit, ca supposerait d’autres solutions pour gérer l’ordre des objets dans spip..

en attendant, pour garder la fonctionnalité, peut-être faut-il mieux trouver un moyen de proposer à l’utilisateur le tri dans un bouton en haut de page... plutôt que de chercher dans les données de la rubrique si c’est pertinent ou non.. ? Car même si je n’utilise pas les numéros dans les titres, j’ai le droit de trier par ordre alpha.. ? Il ne reste alors qu’à utiliser le filtre pour enlever le numéro s’il existe... ?

J’en profite pour relancer une autre question... Malgré tous mes tests, les boutons de recalcul avec cookie ne fonctionne toujours pas sur mon site pam.venissieux.org, sans surcharge de squelette, avec purge tmp + local + cache FF.... toujours rien !!

merci d’avance

pam
8 mars 2009 à 13h46
_Eric_

Logo de _Eric_

Salut Pamillet,

Bon je t’envoie un fichier modifié si tu peux le tester et me dire si cela améliore les performances.
Sinon, j’ai regardé aussi tes mails sur la liste user (c’est pas simple de faire toutes les listes SPIP pour trouver tes demandes...) je suis pas d’accord sur les css en html. Je m’étais renseigné, ça ne pose aucun souci de performance même au contraire et combiné avec le compactage c’est très performant. Le seul hic pour l’instant c’est que j’ai remonté un bug sur le compactage des css quand on utilise la surcharge.

Donc, dis moi stp si cela améliore ou pas.

Concernant la numérotation c’est au contraire très intéressant car elle permet de classer les articles ou rubriques dans l’ordre que tu veux toi, ni par date, ni par ordre alphabétique. Ca n’a rien à voir avec des index. Par contre, je suis pas pour proposer un bouton de tri. Je préfère une configuration une fois pour toute.
8 mars 2009 à 15h52
pamillet

Logo de pamillet

résultat du test.. pas concluant !!

sites/pam.venissieux.org/squelettes/noisettes/rubrique/inc_rubrique_articles.html : squelette résultat code calcul Temps de calcul : 5.428s
#ENV
id_rubrique  : 4
lang  : fr
1 boucle résultat code calcul

la table article a 32 enregistrements..., donc 5 s pour en ramener une dizaine, c’est long !!!

Pour le compactage css, j’avais désactivé tous les compactages spip en phase de développement. Mais en les réactivant, ce n’est pas mieux...

sites/pam.venissieux.org/squelettes/noisettes/rubrique/inc_rubrique_articles.html : squelette résultat code calcul Temps de calcul : 6.600s
#ENV
id_rubrique  : 4
lang  : fr
1 boucle résultat code calcul

Tu ne m’as pas répondu sur le pb de boutons disparu.. ? je ne sais pas ou chercher.. si ce n’est pas dans une balise formulaire, comment je peux vérifier dans le squelette ou ca devrait être ?

Pour les performances, compte tenu du nb de post sur ce sujet qui évoque ovh, je commence vraiment à me demander si’l n’y a pas un pb de coté, avec une ressource SQL fortement consommée par spip2 et faiblement allouée par ovh... Ca ne peut pas être le nb de connexon simulatnée, dans mon cas, je suis sûr qu’il n’a pas eu d’autre connexion en même temps... donc c’est autre chose

Sinon, pour le tri, bien sûr que c’est bien d’avoir un tri indépendant des dates et des descriptions, mais le fait d’utiliser un numéro intégré à la description me surprend. Pourquoi pas un champ "sequence" dans la table, autant pour les articles que les rubriques, et une interface "drag and drop" dans la partie privé pour déplacer un objet dans une liste... ? Après, pour que le squelette permette de définir le tri par rubrique, il faut un code tri par défaut par rubrique, mais il me semble que donner à l’utilisateur le choix du tri est plutôt positif.. sauf si l’éditeur du site veut vraiment le contrôler, auquel cas un statut "tri bloqué/à la demande" général ou par rubrique permet de répondre à toutes les situations ! Il ms semble que pour un squelette généraliste, le mieux est (si ca ne ne complique pas trop), de laisser des alternatives...

mais je m’écarte de ce que je peux faire... donc, juste pour avis d’utilisateur !

pam

PS...
je poste aussi des questions sur la liste spip quand il me semble qu’elles sont sans rapport avec sarka... ai-je tort ?
8 mars 2009 à 16h23
pamillet

Logo de pamillet

complément...
la même requête par phpmyadmin

j’ai récupéré dans le debug la requête, recopié dans phpamydmin
– sql par spip : 5.327s
– sql par phpmyadmin : 0.0018s

... ??

les traces

la requête génére par spip était

SELECT articles.date, articles.id_article, articles.lang
3 FROM spip_articles AS articles
4 WHERE (articles.statut = ’publie’)
5 AND (articles.id_rubrique = 4)
6 ORDER BY articles.date DESC

trace requete sql par phpmyadmin

Affichage des enregistrements 0 - 15 (16 total, Traitement en 0.0018 sec.)
requête SQL :
SELECT articles.date, articles.id_article, articles.lang
FROM spip_articles AS articles
WHERE (
articles.statut = ’publie’
)
AND (
articles.id_rubrique =4
)
ORDER BY articles.date DESC
LIMIT 0 , 30

le debug du site

sites/pam.venissieux.org/squelettes/noisettes/rubrique/inc_rubrique_articles.html : squelette résultat code calcul Temps de calcul : 5.327s
#ENV
id_rubrique  : 4
lang  : fr
1 boucle résultat code calcul