optimisation SPIP-contrib J2

Messages

• 23 décembre 2007, 15:12

  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).

• 23 décembre 2007, 15:15

  Ah non, mince, je n’avais pas compris les notations.
  Tant pis, de toutes façons ça tient dans un mouchoir de poche.

• 23 décembre 2007, 22:19

  Allez, j’en ai remis une couche :
  http://trac.rezo.net/trac/spip/changeset/10995

  Ben, au boulot.

• 31 décembre 2007, 12:13, par Committo, Ergo Sum

  Bon, Stéphane vient de modifier le nom du critère (cf SVN 11019), faut à nouveau modifier le squelette et retester le tout.

• 31 décembre 2007, 19:38, par Committo, Ergo Sum

  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.

• 31 décembre 2007, 23:42, par NicolasR

  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

• 31 décembre 2007, 23:46, par 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) ?

• 1er janvier 2008, 04:12, par Ben.

  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)

• 7 janvier 2008, 23:05, par NicolasR

  pour mémoire http://www.spip-contrib.net/Annonce...

• 12 janvier 2008, 11:08, par Ben.

  Mise à jour de l’article avec la mise à jour du squelette ... nicolas et esj je vous ait ajouté comme auteur pour suivre les discussions

• 12 janvier 2008, 11:29, par Ben.

  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

• 12 janvier 2008, 15:10, par Committo, Ergo Sum

  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)

• 12 janvier 2008, 16:17

  Après des lenteurs assez conséquentes ce matin, spip-contrib plante carrément cet aprèm...

• 12 janvier 2008, 20:08, par Committo, Ergo Sum

  Bon, finalement j’ai réécrit le squelette moi-même mais je n’ai pas les moyens de tester en vraie grandeur.

• 13 janvier 2008, 01:31

  50 requetes de plus de 0,6s pour le sommaire et plus de 1000 requetes pour cette seule page.

• 13 janvier 2008, 08:14, par Committo, Ergo Sum

  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.

• 13 janvier 2008, 19:43, par Committo, Ergo Sum

  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.

• 15 janvier 2008, 10:39, par Committo, Ergo Sum

  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.

• 15 janvier 2008, 10:54, par Ben.

  il faut que je fasse un rechargement de la base originale pour remettre les index et avoir une base propre

• 18 janvier 2008, 00:10, par Ben.

  mise à jour de l’article avec une petite meusure

• 20 janvier 2008, 21:52

  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.

• 6 février 2013, 14:41, par Loiseau2nuit

  Euh... c’est normal que tous les liens en scriibe.net renvoit vers des pages de pub pour Sosh ??? oO