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).
Mais effectivement, il y a pas mal de requetes SQL qui pourraient etre cachees. Ne serais-ce que sur une meme page, il se peut que je fasse appel 10 fois a la meme query, et j'ai l'impression qu'aucun cache n'est etabli. N'y aurait-il pas de plugin qui permettrait de manuellement selectionner en PHP les requetes pouvant etre cachees ? Parce que j'ai li'impression que par defaut MySQL ne fait rien, ce qui m'etonne un peu. Au passage j'ai installe php-fpm sous les conseils d'OVH mais j'ai pas vu de difference... donc OVH est connu pour etre lent sur leurs mutualises de base, c'est pas seulement moi ? 2014-05-04 2:19 GMT-04:00 Philippe <[email protected]>: > 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 > <[email protected]> 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 - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev -- Christopher Crouzet *http://christophercrouzet.com* <http://christophercrouzet.com> -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
