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
