Optimiser une boucle

Bonjour à tous

mon site SPIP contient une rubrique principale (id_rubrique=1). Cette rubrique
contient 4 sous rubriques, contenant eux même plusieurs rubriques et sous
rubriques.

J'utilise la boucle suivante pour afficher la hiéarchie sous forme de menu
déroulant

<ul class="sf-menu">
<BOUCLE_primaire(RUBRIQUES){id_rubrique=1}{par titre}>
  <BOUCLE_secteurs(RUBRIQUES){id_parent}{par titre}>
    <li><a href="#URL_RUBRIQUE">#TITRE</a>
      <B_sousrub>
      <ul>
      <BOUCLE_sousrub(RUBRIQUES){id_parent}{par titre}>
      <li><a href="#URL_RUBRIQUE">#TITRE</a>
        <BOUCLE_sousousrub(boucle_sousrub)></BOUCLE_sousousrub>
      </li>
      </BOUCLE_sousrub>
      </ul>
      </B_sousrub>
    </li>
  </BOUCLE_secteurs>
</BOUCLE_primaire>
</ul>

Le problème, c'est que lorsque je passe en mode debug, je me rends compte que
le temps de calcul de cette rubrique est très long (près de 3 secondes).

Est-il possible de travailler cette boucle différement pour en optimiser le
temps d'exécution ?

Je vous remercie pour votre aide.

Manu a écrit :

Bonjour à tous

mon site SPIP contient une rubrique principale (id_rubrique=1). Cette rubrique
contient 4 sous rubriques, contenant eux même plusieurs rubriques et sous
rubriques.

J'utilise la boucle suivante pour afficher la hiéarchie sous forme de menu
déroulant

<ul class="sf-menu">
<BOUCLE_primaire(RUBRIQUES){id_rubrique=1}{par titre}>
  <BOUCLE_secteurs(RUBRIQUES){id_parent}{par titre}>
    <li><a href="#URL_RUBRIQUE">#TITRE</a>
      <B_sousrub>
      <ul>
      <BOUCLE_sousrub(RUBRIQUES){id_parent}{par titre}>
      <li><a href="#URL_RUBRIQUE">#TITRE</a>
        <BOUCLE_sousousrub(boucle_sousrub)></BOUCLE_sousousrub>
      </li>
      </BOUCLE_sousrub>
      </ul>
      </B_sousrub>
    </li>
  </BOUCLE_secteurs>
</BOUCLE_primaire>
</ul>

Le problème, c'est que lorsque je passe en mode debug, je me rends compte que
le temps de calcul de cette rubrique est très long (près de 3 secondes).

Est-il possible de travailler cette boucle différement pour en optimiser le
temps d'exécution ?

Je vous remercie pour votre aide.

Tu peux déjà gagner une boucle avec

<BOUCLE_secteurs(RUBRIQUES){id_parent=1}{par titre}>

Mais je ne suis pas sûr que cela fasse gagner beaucoup de temps

FDM

Manu a écrit :

Est-il possible de travailler cette boucle différement pour en optimiser le temps d'exécution ?

déjà, comme le fait remarquer françois, tu peux
te dispenser de la boucle _primaire

<ul>
<BOUCLE_secteurs(RUBRIQUES){id_parent=1}{par titre}>
   ...
</BOUCLE_secteurs>
</ul>

ce qui pèse dans les requêtes suivantes, c'est le 'order by'
généré par les {par titre}.
à voir si ce tri t'est vraiment indispensable...

aussi, tu peux déporter ces boucles dans un inclure avec un cache
trés long. ainsi, même si leur temps de calcul est (trés) long,
il ne sera 'réel' qu'une fois tous les 36 du mois.

Je poursuis mes investigations. Si la boucle calculant le menu est très longues,
je constates que celles donnant le plan du site est encore plus longues.

En regardant ce qui se passe dans les logs, je note les lignes suivantes dans
spip.log :

COMPIL (0.140s) [squelettes/plan] html_0688f2a26597a29242b1a7535e7452b8.php
calcul (14.980s) [squelettes/plan] page=plan, date='2009-09-18 14:37:50',
date_default=1, date_redac='2009-09-18 14:37:50', date_redac_default=1 (44993
octets)
Creation du cache 3/plan%2Fspip%2Fspip-plan--2299d5d7 pour 86400 secondes

Quelle est la différence entre COMPIL et calcul ?
Je pense que le problème n'est pas du côté SPIP mais plutôt du serveur mais je
ne sais pas par où commencer...
si le calcul est si long, d'après vos connaissances, quelle pourrait en être
l'origine ?

Merci pour votre aide.
Manu

Manu a écrit :

Quelle est la différence entre COMPIL et calcul ?

COMPIL = compilation du squelette (=> transforme le squelette en code PHP)
calcul = execution du squelette compilé (donc accès base de donnée et generation du fichier de cache)

Je pense que le problème n'est pas du côté SPIP mais plutôt du serveur mais je
ne sais pas par où commencer...

commence par ajouter &var_mode=recalcul&var_profile=mysql à la fin de ton url, en etant en admin

si le calcul est si long, d'après vos connaissances, quelle pourrait en être
l'origine ?

acces restreint sans doute.
combien de rubriques sont en accès restreint dans ton site ?

@++

Stephane <stephane <at> rezo.net> writes:

commence par ajouter &var_mode=recalcul&var_profile=mysql à la fin de
ton url, en etant en admin

C'est fait. Je récupère des tas de chiffres mais les temps indiqués sont
faibles. Si j'ai bien compris, ça affiche le temps d'exécution des requêtes SQL
nécessaires à la "fabrication" de la page ?
Or le temps total est de 0,2 secondes.

acces restreint sans doute.
combien de rubriques sont en accès restreint dans ton site ?

Oui le plugin est actif sur le site, pour une seule rubrique. Je viens de le
désactiver, j'ai purgé le cache et c'est toujours aussi long....

Manu a écrit :

Stephane <stephane <at> rezo.net> writes:

commence par ajouter &var_mode=recalcul&var_profile=mysql à la fin de ton url, en etant en admin

C'est fait. Je récupère des tas de chiffres mais les temps indiqués sont
faibles. Si j'ai bien compris, ça affiche le temps d'exécution des requêtes SQL
nécessaires à la "fabrication" de la page ?
Or le temps total est de 0,2 secondes.

heu, j'ai du mal à comprendre.
ton 3s de calcul, tu le sors d'ou ?
peux-tu refaire le test (var_profile) après vidage de cache ?

acces restreint sans doute.
combien de rubriques sont en accès restreint dans ton site ?

Oui le plugin est actif sur le site, pour une seule rubrique. Je viens de le
désactiver, j'ai purgé le cache et c'est toujours aussi long....

De memoire, le probleme de perf se pose uniquement si il y a beaucoup de rubriques en acces restreint (elle n'a pas de sous-rubriques ta rubrique en acces restreint ?)

Manu a écrit :

Si j'ai bien compris, ça affiche le temps d'exécution des requêtes SQL
nécessaires à la "fabrication" de la page ?
Or le temps total est de 0,2 secondes.

si avec var_profile tu ne détectes pas de requête trés lourde,
alors il est possible que ce soit la génération html qui pèse autant
sur la fabrication du cache.

essaie de bâtir une page le_test.html (appelée par ?page=le_test)
qui ne contienne *que* les boucles que tu nous a présentées.
puis regarde spip.log pour connaitre les temps de compil et
de calcul de cette page le_test.

Bon, je récapitule car avec le recul en effet ce n'est pas clair.

J'ai commencé ce sujet en évoquant une boucle utilisée pour créer un menu avec
les sous menus. Puis je me suis aperçu que j'avais le même souci sur d'autres
pages, et notamment celle utilisée pour construire le plan du site. De manière
générale, mon site est très lent et j'essaie de voir où ça coince.

au niveau de la page PLAN.HTML, quelques infos :

- la boucle
<ul class="plansite">
<BOUCLE_secteurs(RUBRIQUES) {id_rubrique=1} {par titre}>
<B_rubriques>
  <ul class="plan-rubriques">
    <BOUCLE_rubriques(RUBRIQUES) {id_parent} {par titre}>
      <li>
      [(#LOGO_RUBRIQUE)]<a href="#URL_RUBRIQUE">[(#TITRE)]</a>
      <B_compte>
      <BOUCLE_compte(ARTICLES) {id_rubrique} {par titre}> </BOUCLE_compte>
      [ - (#TOTAL_BOUCLE) [(#TOTAL_BOUCLE|>{1}|?{'articles','article'})]]
      </B_compte>
      <BOUCLE_sous_rubriques(BOUCLE_rubriques)></BOUCLE_sous_rubriques>
      </li>
    </BOUCLE_rubriques>
  </ul>
</B_rubriques>
</BOUCLE_secteurs>
</ul>

- dans spip.log, après avoir vidé le cache, et appelé la page par l'url
http://nom_du_site/spip.php?page=plan&var_mode=calcul, je trouve les infos
suivantes :
COMPIL (0.162s) [squelettes/plan] html_0688f2a26597a29242b1a7535e7452b8.php
calcul ***(14.352s)*** [squelettes/plan] page=plan, date='2009-09-21 11:06:56',
date_default=1, date_redac='2009-09-21 11:06:56', date_redac_default=1 (44990
octets)

- après avoir de nouveau vidé le cache, et appelé la page par l'url
http://nom_du_site/spip.php?page=plan&var_mode=recalcul&var_profile=mysql, je
trouve les infos suivantes :
573 total : 0.682339836685

Bref, si je comprends bien les infos disponibles, la partie MySql fonctionne
correctement (environ 0.7 secondes) et ce serait bien la génération squelette
--> HTML (plus de 14 secondes) qui poserait problème.

Mon diagnostic est-il le bon ?
Si oui, quelle piste puis-je explorer pour changer la situation ?

Encore merci pour votre aide.
Manu

Vraiment personne ? :frowning:

Manu a écrit :

Vraiment personne ? :frowning:

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Discuter chez rezo.net

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

Tu devrais rappeler la boucle dans le corps de ton message car là, comme ça ??? :wink:

BB

Tu devrais rappeler la boucle dans le corps de ton message car là, comme
ça ??? :wink:

BB

Ben tout est dans mon message juste au dessus (celui du 21/09 à 11h28).
Je redonne la boucle, les tests effectués, les résultats obtenus...