optimisation SPIP-contrib J2
Par Ben., esj, NicolasR, dimanche 23 décembre 2007 à 14:21 :: SPIP-Contrib ::#442
Du boulot sur la planche aujourd’hui ... il faut tester ces 2 propositions par Renato et Esj
J’ai un problème, il faut que je calcule les temps sans cache (oui on commence déjà par optimiser la partie sans cache, après on verra) . Pour être sur de ne pas utiliser le cache, il "suffit" d’utiliser le plugin desactiver cache
Original
SPIP : 10990
SPIP-zone : 17626
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 6.315218 seconds
Renato
On met à jour le squelette et on bénificie de l’optim de Renato
SPIP : 10990
SPIP-zone : 17643
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 3.367852 seconds
Esj
On met à jour SPIP et on profite de l’optim d’ Esj
SPIP : 10992
SPIP-zone : 17643
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 3.366328 seconds
Bon en fait, rien puisqu’il faut changer un peu le squelette .
+Esj-Renato
Alors modifions le squelette ... mais mais, mince, évidemment Renato et Esj ont bossés sur la même requete ;-)
finalement on a
SPIP : 10992
SPIP-zone : 17644
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 3.797988 seconds
upgrade version SPIP (31 dec)
SPIP : 11018
SPIP-zone : 17644
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 3.912825 seconds
upgrade squelette contrib (12 janvier)
SPIP : 11018
SPIP-zone : 17969
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 5.543932 seconds
upgrade SPIP (12 janvier)
SPIP : 11061
SPIP-zone : 17969
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 5.489119 seconds
upgrade squelette contrib (12 janvier)
SPIP : 11065
SPIP-zone : 17985
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 3.194951 seconds
upgrade plugin nuage + svn (18 janvier)
SPIP : 11107
SPIP-zone : 18088
ab -c 1 -n 1 http://spipcontrib.scriibe.net/
Time taken for tests : 3.152876 seconds
Commentaires
C’est nicolasr qui va être content : c’est le squelette le plus simple qui bénéficie du meilleur du temps.
Je viens de rajouter une petite optimisation supplémentaire (http://trac.rezo.net/trac/spip/changeset/10993) peut-être que ça permettra d’aller jusqu’à la division par 2 de la durée initiale (on y est presque).
Ah non, mince, je n’avais pas compris les notations.
Tant pis, de toutes façons ça tient dans un mouchoir de poche.
Allez, j’en ai remis une couche :
http://trac.rezo.net/trac/spip/changeset/10995
Ben, au boulot.
Bon, Stéphane vient de modifier le nom du critère (cf SVN 11019), faut à nouveau modifier le squelette et retester le tout.
Bon, eh bien l’interprétation de ces mesures montre que se focaliser sur l’optimalité des requêtes SQL n’est pas forcément le bon plan : visiblement ce qu’on a gagné en SQL est plus que perdu en PHP. Et vu la petitesse du code introduit, ça pose des questions sur la marge d’erreur dans la mesure.
Seule chose sûre : l’exercice est clos.
Il y a autre chose
J’abonde dans le sens de committo .... quelques constats pratiques :
l’interface privée devient parfois très lente, limite insupportable, et c’est une chose que je constate régulièrement particulièrement le soir. Dans ce cas de figure il est clair que les squelettes publics ne sont pas concernés
idem pour la recherche privée, qui utilise pourtant d’après ce que je crois les outils natifs de mysql et non l’indexation de spip 1.9.2
par exemple la page "auteur" est purement celle de la dist 2007 (du moins à ce jour), pourtant elle peut être aussi parfois très lente
le sentiment de lenteur n’est pas constant, parfois c’est correct, parfois c’est à la limite du supportable (avec même des refus d’accès ou des pages blanches).
Je parle ici du vécu coté navigateur, pas de l’usage des ressources coté serveurs.
@+ NicolasR
PS : et encore une fois je ne comprends pas que le(s) cache(s) n’atténue(ent) pas plus ces temps de recalculs éventuellement trop long. Tout ce passe comme si il y avait quelque chose qui soit force le recalcul trop fréquent, soit limite les gains du cache en terme de mise à disposition du navigateur d’une page déjà calculée, soit laisse dans chaque page beaucoup de choses à recalculer par le navigateur de chacun.
Question au jugé : quid des bibliothèques, par exemple pour le calcul des vignettes (il y en beaucoup sur SPIP-Contrib) ?
bon bon bon cela fait un peu stérile ce débat interposé par commentaire mais bon je précise une ou deux choses.
Si ta page sommaire est recalculée et que cela prend 10 secondes, et que pendant ce temps là tu consultes une page de l’espace privé, et bien ton espace privé peut être ralenti
La page sommaire prenait (c’est juste une mesure, pas forcement fiable mais c’est une mesure) 6 secondes avant, 4 secondes maintenant . La page sommaire de la dist prend 1 seconde (mais elle ne contient pas toutes les fonctionnalités je suis d’accord)
pour mémoire http://www.spip-contrib.net/Annonce...
Mise à jour de l’article avec la mise à jour du squelette ... nicolas et esj je vous ait ajouté comme auteur pour suivre les discussions
avec le var_profile (faut être loggué en tant qu’admin) on voit maintenant que l’on a 800 requetes au total (contre les 1200 du départ) ... il y en a 2 plus longues que les autre
Il y a une requête qui me surprend (id_article=0 !).
Je viens d’améliorer le débusqueur (11062), pour pouvoir voir d’où elle vient.
Par ailleurs, la modif zone17969 est une régression, on peut revenir à une boucle en remplaçant id_mot par id_mot_syndic dans le code précédent (cf 11019)
Après des lenteurs assez conséquentes ce matin, spip-contrib plante carrément cet aprèm...
Bon, finalement j’ai réécrit le squelette moi-même mais je n’ai pas les moyens de tester en vraie grandeur.
50 requetes de plus de 0,6s pour le sommaire et plus de 1000 requetes pour cette seule page.
Bon, la dernière mesure du 12 Janvier sur le site de test a moins de 500 requêtes dont une seule de plus d’une demi seconde. C’est essentiellement dû au retour de la triple jointure, et c’est même un peu mieux grâce à quelques améliorations sur le code PHP compilé.
SVP ne pas mélanger les messages concernant spip-contrib et ceux concernant le site de test sans le dire clairement.
Avec le mode var_profile, je viens de voir que la requête dépassant la demi-seconde choisit comme index "statut", plutot que de choisir la PrimaryKey qui pourtant intervient beaucoup plus souvent dans le Where.
Je suis curieux de voir la mesure que ça donnerait si on ’enlève cet index pour forcer SQL à prendre la PKey (enfin j’espère). Cela dit, il sert systématiquement dans le script d’accueil de l’espace privé, ce serait brutal de l’enlever entièrement même si le test pour Spip-Contrib est concluant.
Les essais avec le retrait de cet index ont été négatifs, la PKey n’étant pas prise pour autant.
En revanche, c’est le plugin Nuage embarqué dans le sommaire de spip-contrib qui est responsable de la boucle avec id_article à 0 mentionnée plus haut, c’est sur lui qu’il faut un peu travailler maintenant.
il faut que je fasse un rechargement de la base originale pour remettre les index et avoir une base propre
mise à jour de l’article avec une petite meusure
Bon, donc avec la réécriture du plugin Nuages, on atteint pile poil la division par 2 du temps de production de la page d’accueil par rapport à l’original. Comme quoi SPIP n’est pas lent en soi, mais commence à demander un peu de doigté pour l’utiliser au mieux.