Pour ma part, et notamment chez OVH qui a sur certains serveurs sql des temps de réaction très importants, j'utilise le plugin staticCache, dont une option permet justement de ne pas se connecter du tout à la base si rien n'a changé. -- Philippe Le 4 mai 2014 01:16, Christopher Crouzet <christopher.crouzet(a)gmail.com&gt; a écrit : > ¡Hola! > > > Je me suis recemment rendu compte que mon site a tendance a se trainer > enormement avec des temps au First Byte pouvant atteindre les 2 secondes > selon webpagetest.org. > Etant donne qu'en local les temps de chargement sont instantane, je me dis > qu'OVH pouvait ne pas etre super performant pour traiter les requetes SQL, > mais je me suis lance dans un premier profiling sommaire des requestes SQL, > histoire de. > > Je suis tombe sur un truc tout bete qui pourrait etre ameliore—donner > l'option de query des posts de maniere plus rapide quand on a besoin > seulement de tres peu d'informations. > Par exemple, dans mon cas j'utilise seulement les champs `post_url` et > `post_title` quand je me sers de `<tpl:EntryNext>` et `<tpl:EntryPreview>`. > J'ai donc ecrit mes propre blocks tpl `EntryNext/Preview` et ai remplace > l'appel a la fonction `dcBlog::getNextPost` par `dcBlog::getPosts` avec le > parametre `no_content` active. > > Mais ca se traine toujours un peu. > > > SELECT > P.post_id, P.blog_id, P.user_id, P.cat_id, > post_dt, post_tz, post_creadt, post_upddt, post_format, post_password, > post_url, post_lang, post_title, post_type, post_meta, post_status, > post_selected, post_position, post_open_comment, post_open_tb, nb_comment, > nb_trackback, > U.user_name, U.user_firstname, U.user_displayname, U.user_email, > U.user_url, > C.cat_title, C.cat_url, C.cat_desc > FROM dc_post P > > INNER JOIN dc_user U ON U.user_id = P.user_id > > LEFT OUTER JOIN dc_category C ON P.cat_id = C.cat_id > > WHERE P.blog_id = 'default' AND > ((post_status = 1 AND post_password IS NULL ) ) AND > post_type IN ('post') AND > ( (post_dt = '2013-11-22 00:00:00' AND P.post_id > 1) OR post_dt > > '2013-11-22 00:00:00' ) > > ORDER BY post_dt ASC, P.post_id ASC > > LIMIT 1 > > > La requete ci-dessus prend entre 2.5 ms et 5 ms en local et... peut monter > jusqu'a 200-600 ms chez OVH si l'alignement des etoiles n'est pas optimal. > Maintenant, la meme requete sans les champs `post_meta` et `C.cat_desc` > prend entre 0.8 ms et 1 ms en local pour 2-5.5 ms chez OVH. > > Alors effectivement il semble y avoir des problemes chez OVH, mais la > difference est d'un facteur 100 dans mon cas, ce qui n'est pas negligeable > tant de maniere relative qu'absolue. > > > Du coup, est-ce que ca vous semblerait etre une bonne idee de rajouter un > parametre `fast` a la methode `dcBlog::getPosts` qui n'ajouterait pas ces > champs-la ? Ou peut-etre pour plus de flexibilite (et dangerosite) ajouter > un parametre qui contiendrait les champs a exclure de la query ? > Je me suis rendu compte en faisant ca que certains champs sont obligatoires > pour que les extensions `rsExtPost` et autres fonctionnent bien, mais ca > devrait pouvoir etre contournable ? > Si l'idee vous interesse, je pourrais eventuellement me porter volontaire > pour le code si vous etes trop occupes. > > > Bonne journee, > Christopher. > > > -- > Christopher Crouzet > *http://christophercrouzet.com* <http://christophercrouzet.com> > -- > Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 4 mai 2014 15:24, Christopher Crouzet <christopher.crouzet(a)gmail.com&gt; a écrit : > J'y connais vraiment pas grand chose en cache mais je ne pense pas que > staticCache marcherait dans mon cas—par exemple a chaque affichage de l'un > de mes posts, j'aimerais que la liste de posts recommandes soit regeneree > (ca retourne de maniere aleatoire 4 des 8 posts les plus populaires). Dans ce cas effectivement ça ne va pas marcher ^^ Mais Bruno a fait un plougue qui permet de choisir plus finement les pages mises en cache. Dans ton cas, mettre en cache la home, les catégories, les tags, etc. et ne faire générer à chaque fois que post.html permettrait de soulager un peu le serveur, non ? Reste ensuite des règles d'expiration de fichiers dans le .htaccess, l'utilisation de sprites pour les images de déco, éventuellement un domaine sans cookie pour les fichiers statiques, bref il y a pas mal de choses à faire côté performances, sans bien entendu remettre en cause la possibilité d'optimiser les requêtes de dotclear, mais probablement plus efficaces ;) Concernant ta remarque sur OVH et ses bugs sur le temps d'accès aux bases, c'est à mon avis tout à fait avéré, ça râle même beaucoup sur leur forum... -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

> Une question pour Bruno : pour la page post.html par exemple, est-ce que > faircache genere le cache d'un article lorsqu'il est update dans la partie > admin ou lorsqu'un visiteur charge la page pour une premiere fois ? Dans > l'idee ca serait bien si un visiteur n'aurait pas a payer pour tous les > autres... surtout si le visiteur en question s'appelle GoogleBot ! :) > J'ai ma reponse, c'est non :) Bizarrement, meme avec faircache d'active (et de fonctionnel) sur mon site, les resultats au First Byte sont toujours aussi mauvais : http://www.webpagetest.org/result/140504_NQ_3ff67e89ae61ce72b3c4ff5905842... Ca devient mysterieux.

Merci Philippe, je vais me servir de ce lien pour ma reponse au support. Au lieu d'accepeter leur offre d'analyser mon probleme en echange de 20€, je vais leur proposer d'arranger leur probleme de serveur sinon je me casse. Bruno : effectivement, ca fait du sens. Ne serais-ce du coup pas plus efficace si un systeme de cache serait inclu directement dans Dotclear en rajoutant un nouveau parametre `cacheable` pour chaque fonction faisant des requetes SQL, comme `dcBlog::getPosts` ? Ensuite ca serait facile de faire des options globales dans la partie admin pour permettre de cacher les queries SQL des posts et autres, tout en donnant ensuite la possibilite de faire un cache plus selectif avec une option `cacheable="1"` pour chaque balise tpl, comme le fait fairCache. Au plus j'y pense au plus ca semble logique d'avoir un cache parfaitement integre dans le core qui puisse se generer sans failles lorsque des operations sont faites dans l'admin par exemple. Mais ca semble etre pas mal de boulot ! :)

> > > > Du coup, est-ce que ca vous semblerait etre une bonne idee de rajouter un > parametre `fast` a la methode `dcBlog::getPosts` qui n'ajouterait pas ces > champs-la ? Ou peut-etre pour plus de flexibilite (et dangerosite) ajouter > un parametre qui contiendrait les champs a exclure de la query ? > Je me suis rendu compte en faisant ca que certains champs sont obligatoires > pour que les extensions `rsExtPost` et autres fonctionnent bien, mais ca > devrait pouvoir etre contournable ? > Si l'idee vous interesse, je pourrais eventuellement me porter volontaire > pour le code si vous etes trop occupes. > Hello, Je pense que cela pourra se faire plus simplement quand on passera au select statement que j'ai proposé récemment ( http://ml.dotclear.org/pipermail/dev/2014-March/009106.html) Actuellement beaucoup de choses sont codées en dur dans ces méthodes, ajouter un behavior qui permet d'agir sur un statement autoriserait le genre de simplifications que tu proposes. -- Bruno -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev