¡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>