[spip-dev] spip-contrib.net Down - [Site24x7]

Dev
1

Bonjour,

ne peut-on pas trouver un moyen pour avoir un spip-contrib qui tienne la route ? Il est trop souvent en rade, et possède des temps de réponse monstrueux. C’est à mes yeux le second site le plus important de SPIP, et c’est l’image même du CMS qui y est véhiculée. Spip-contrib devrait être l’état de l’art d’une bonne installation de SPIP, ou alors le néophyte va penser que SPIP est vraiment un Machin qui rame à mort.

Et puis sans compter que ça ne donne pas envie de surfer dessus, vu le temps que ça met à charger…

La situation s’est particulièrement dégradée cette année : on est victime de notre succès ?
Diagramme de cette semaine : http://tinyurl.com/2kbl3k
Résumé pour l’année 2007 : http://tinyurl.com/3ykjjf
Résumé pour l’année 2006 : http://tinyurl.com/2ups2m

Au delà du temps de réponse, j’y retiens un taux d’indisponibilité de 5 à 8%, c’est monstreux :((

.Gilles

PS.: Dans ce monitoring externe (une fois par 1/2 heure puis toutes les minutes en cas de non-réponse), seule la page d’accueil de spip-contrib est testée, normalement on devrait s’attendre à peu de pics dans les temps de réponse, voire une réponse optimale vu que c’est quand même la page la plus visitée…

2

bonjour Gilles,
merci pour ton post

par contre je ne comprends pas trop pourquoi le dowtime serait
systematiquement de 30 minutes , il n'y a pas de raisons . Ce n'est
pas l'outil qui déconne ?

3

par contre je ne comprends pas trop pourquoi le dowtime serait
systematiquement de 30 minutes , il n'y a pas de raisons . Ce n'est
pas l'outil qui déconne ?

Non, c'est la fréquence de ping normal, que j'avais, il y a 2 ans,
réglé à 30mn pour ne pas charger le serveur. En fait, ca ne varie pas
A nuancer aussi, la signification du temps de réponse trop long (qui
n'est pas forcément que lié au serveur ou à SPIP, il y a le réseau
entre -- la machine est aux US), mais la tendance est réelle, et la
courbe est vraiment en dent de scie (ce qui est moins le cas dans
d'autres sites que je surveille)
J'aurais pu mettre un ping toutes les 5mns, mais bon, ça n'aurait
peut-être pas donné plus d'information

Sinon, j'ai bien la page d'accueil de spip.net en veille, mais vu que
le calcul y est faible, ça explique des temps de réponse très courts
(ex. http://tinyurl.com/yu64dn pour ce mois et
http://tinyurl.com/2szyza pour cette année) -- mais ça donne une idée
de l'importance de l'effet global du réseau comme perturbation pour la
mesure, finalement très faible..

.Gilles

4

Gilles Vincent a écrit :

ne peut-on pas trouver un moyen pour avoir un spip-contrib qui tienne la route ? Il est trop souvent en rade, et possède des temps de réponse monstrueux.

Bon... zut, je n'arrivais justement pas à m'y connecter là, mais c'est revenu ! C'est vrai que contrib est un site extrèmement important qui contient l'essentiel de la documentation des plugins. Je trouve aussi dommage qu'il soit très lent (sur les recherches particulièrement)

Le moyen c'est quoi ? C'est le déplacer sur/louer/financer un serveur plus puissant ? Expresso-er ou FastCacher certaines pages ? Mettre SPIP à jour (des requetes ont peut être été optimisées depuis [8813]) ? Supprimer les {pagination} sur la page d'accueil ? simplifier le squelette ?

MM.

Il me semblait que le squelette /dist proposé aussi sur contrib allait plus vite. Petit test (pas très objectif vu que je n'ai fait qu'un essai pour cahque) mais qui montre bien une grosse différence entre les 2 squelettes :

Testouilles var_profile sur la page d'accueil

5

Gilles Vincent a écrit :

Bonjour,

ne peut-on pas trouver un moyen pour avoir un spip-contrib qui tienne la route ? Il est trop souvent en rade, et possède des temps de réponse monstrueux. C'est à mes yeux le second site le plus important de SPIP,

Ah, oui, une autre testouille toujours sur la page d'accueil a été un peu plus clémente avec le squelette de contrib (promis, j'arrête maintenant ^^) :

+ 1.00s : 0
+ 0.10s : 100
+ 0.01s : 177
   total : 1518 requetes.

MM.

6

Le moyen c'est quoi ? C'est le déplacer sur/louer/financer un serveur
plus puissant ?

je pense que les squelettes sont trop lourds, il faudrait en
particulier nettoyer les {doublons} qui produisent la requête
monstrueuse que tu nous a envoyée.

Expresso-er ou FastCacher certaines pages ?

ça ne peut pas faire de mal mais ça n'est pas vraimnt ça le problème

Recap.
temps : nombre
+ 1.00s : 6
+ 0.10s : 110
+ 0.01s : 230
   total : 1375 requetes

-- sur le squelette DIST :

+ 1.00s : 0
+ 0.10s : 1
+ 0.01s : 33
   total : 259 requetes

Je crois que c'est clair :stuck_out_tongue:

-- Fil

7

Fil a écrit :

Le moyen c'est quoi ? C'est le déplacer sur/louer/financer un serveur
plus puissant ?

je pense que les squelettes sont trop lourds, il faudrait en
particulier nettoyer les {doublons} qui produisent la requête
monstrueuse que tu nous a envoyée.

La (et les) requetes proviennent de ça :
[(#REM) Suivi des seuls commits de la Zone syndiques sur Contrib - via usage du critere antidoublons ]
<BOUCLE_motsiteszone(MOTS){id_mot=233}>
         <BOUCLE_siteszone(SITES){id_mot}><BOUCLE_syndiczone(SYNDIC_ARTICLES){id_syndic}{doublons zone}></BOUCLE_syndiczone></BOUCLE_siteszone>
</BOUCLE_motsiteszone>

Et de l'utilisation ensuite de {doublons zone} et {!doublons zone} dans d'autres boucles.

Cette boucle déjà est extrèmement couteuse.
Une suggestion est de syndiquer directement la 'zone' et non pas simplement toutes les contributions qui ont une entrée dans la zone (car ça fait un nombre bien trop grand d'articles à parcourir)

Ca allègerait un gros poids.

Sinon, il y a aussi #SET et #GET qui pourraient être empolyés à la place de {doublons} ici.

Expresso-er ou FastCacher certaines pages ?

Tiens, FastCache est dessus ? tu l'as installé ?

MM.

8

Matthieu Marcillaud ha scritto:
  > La (et les) requetes proviennent de ça :

[(#REM) Suivi des seuls commits de la Zone syndiques sur Contrib - via usage du critere antidoublons ]
<BOUCLE_motsiteszone(MOTS){id_mot=233}>
         <BOUCLE_siteszone(SITES){id_mot}><BOUCLE_syndiczone(SYNDIC_ARTICLES){id_syndic}{doublons zone}></BOUCLE_syndiczone></BOUCLE_siteszone>
</BOUCLE_motsiteszone>

Et de l'utilisation ensuite de {doublons zone} et {!doublons zone} dans d'autres boucles.

Cette boucle déjà est extrèmement couteuse.
Une suggestion est de syndiquer directement la 'zone' et non pas simplement toutes les contributions qui ont une entrée dans la zone (car ça fait un nombre bien trop grand d'articles à parcourir)

Ca allègerait un gros poids.

Sinon, il y a aussi #SET et #GET qui pourraient être empolyés à la place de {doublons} ici.

J'ai pas teste, mais quelque chose comme ça peut améliorer:

http://spip.pastebin.com/m4e096218

J'ai utilise array_push car la version SPIP de contrib a pas de filtre push.

Renato

9

bin oui mais vous êtes bien gentils avec ce genre de remarque. Il me semble que la vous inversez l'ordre des valeurs. La technique doit être au service de l'usage et des utilisateurs pas le contraire. Ici vous proposez de débarquer les bagages pour alléger le véhicule, en oubliant que c'est peut être la fonction de ce véhicule que d'être capable de transporter les dits bagages, et avec une conduite accessible aux conducteurs/moyens (dans mon genre) pas réservée aux seuls mécaniciens avertis.

le "nettoyage" dont on parle ci-dessus ne s'occupe que des problemes techniques, pas de la raison éditoriale, c'est le monde à l'envers

Après c'est aux devs d'avoir un discours cohérent : si vous proposez des fonctions "de base et depuis longtemps" (ici les doublons) qui ne sont utilisables qu'avec moults précautions, à minima produisez l'information adéquate et fournissez le compteur de suivi qui va bien, pas des trucs comme on m'a expliqué hier ou avant-hier ou il faut calculer à partir du régime moteur, des rapports de boites et du diamètre des pneux simplement pour savoir si on est en excès de vitesse ou pas (c'est faisable bien sur mais ça limite les utilisateurs).

Dans le cas d'espèce dont on parle, les requêtes dont on parle viennent de l'usage des doublons et parfois antidoublons. J'avoue que j'en fait un usage généreux car à ma connaissance c'est le seul moyen parfois, pour une webmaster de base dans mon genre, de construire des requêtes un peu fines pour présenter "ce que l'on veut" ou "l'on veut" en fonction des besoins éditoriaux, et non pas l'inverse d'adapter les besoins éditoriaux au machin. Personnellement c'est cette souplesse qui est une des raison principales qui me font apprécier SPIP

et ne me dites pas que la seul réponse est de revenir à une présentation standard, anonyme, façon dist, ou d'être dev pour pouvoir le mettre en oeuvre ... si c'est oui c'est pas la peine de le tuner en permanence, si le pékin moyen ne peut plus se servir de fonction, qui je le rappelle sont la depuis longtemps (ici les doublons)

@+ NicolasR qui s'interroge sur ce qu'il vient faire dans cette galère

10

La (et les) requetes proviennent de ça :
[(#REM) Suivi des seuls commits de la Zone syndiques sur Contrib - via
usage du critere antidoublons ]
<BOUCLE_motsiteszone(MOTS){id_mot=233}>
<BOUCLE_siteszone(SITES){id_mot}><BOUCLE_syndiczone(SYNDIC_ARTICLES){id_syndic}{doublons
zone}></BOUCLE_syndiczone></BOUCLE_siteszone>
</BOUCLE_motsiteszone>

Et de l'utilisation ensuite de {doublons zone} et {!doublons zone} dans
d'autres boucles.

Cette boucle déjà est extrèmement couteuse.
Une suggestion est de syndiquer directement la 'zone' et non pas
simplement toutes les contributions qui ont une entrée dans la zone (car
ça fait un nombre bien trop grand d'articles à parcourir)
Ca allègerait un gros poids.

Tu propose de faire autre chose que l'objectif éditorial qui est clairement annoncé au début .
si une simple boucle comme celle qui est donnée ci-dessus, et qui utilise des fonctions en service depuis longtemps sur SPIP, peut mettre un serveur à genoux, il y a quand même des question à se poser .... pareil s'il s'avère nécessaire de réunir un aéropage de coredevs pour en gérer la gérer.

Si je comprends bien SPIP met à disposition de tout un chacun de quoi faire sauter la baraque sans même à minima proposer des alarmes ?

Sinon, il y a aussi #SET et #GET qui pourraient être empolyés à la place
de {doublons} ici.

ah bon ... envoi les explications, cela sera l'occasion d'améliorer la doc, perso j'ai jamais rien compris à ces trucs (je dois être trop naze).

@+ NicolasR

11

* Matthieu Marcillaud tapuscrivait, le 16/12/2007 11:02:

Testouilles var_profile sur la page d'accueil
---------------------------------------------
Requete la plus gourmande sur le squelette contrib (3,32s) :

SELECT syndic_articles.id_syndic_article FROM `spip`.spip_syndic_articles AS `syndic_articles`, `spip`.spip_syndic AS `J1` WHERE (syndic_articles.id_syndic = '265') AND ((syndic_articles.id_syndic_article NOT IN

<snip>
Est-ce que par hasard, var_profile, en plus d'indiquer le temps et la requête
pourrait aussi indiquer le nom de la boucle (et de son squelette) ?

12

"un trop grand nombre d'articles" ??? la je m'interroge.

Je rappelle qu'il ne s'agit la que de parcourir quelques centaines d'articles (à peine plus de de 1000 à tout casser hors Gribouille, et encore moins si l'on déduit ceux qui sont taggés archives) et ce qui plus est une seule fois par heure en théorie (cache à 3600, bon d'accord plus avec les invalidations de caches dues aux forums). Ce nombre est quand même très courant, et pour mémoire SPIP se targue de pouvoir gérer une base de 180 000 articles (l'huma).

Pour en revenir aux {doublons} et {!anti doublons}, qui sont un moyen accessible au commun des mortels de stocker le résultat d'une recherche et de s'en resservir ailleurs (de construire des ET entre autre), il me semble en parlant de lourdeur des requêtes (et de l'usage des caches) qu'il y a un vrai manque actuellement : on peut s'en servir actuellement seulement à l'intérieur d'une même page (et encore pas dans les INCLURE). De ce fait il faut souvent répéter de page en page les mêmes boucles pour des requêtes récurentes , ce qui est certainement pénalisant.

J'avais déjà posé la question sur cette liste il y a quelques temps "http://archives.rezo.net/spip-dev.mbox/200708.mbox/<e13f0d7290b6b28649e271da1f1b28a1@free.fr>" mais le débat s'était enlisée sur un sous-cas d'espece (les archives) en oubliant le sujet du départ (calculer une seule fois les piles récurentes)

Encore une fois {doublons} et {!anti doublons} ne sont pas fonctions exotiques au comportement aléatoires, mais de fonctions de base et anciennes du core, et abondamment citées comme un moyen accessible à utiliser, et pas pour des requettes basique , exemple : "http://archives.rezo.net/spip-zone.mbox/200710.mbox/<471329E5.8050401@yterium.com>" ou Cédric dit "Cela pourrait encore s'optimiser en evitant completement les boucles inutiles (celles pour lequel le #ENV n'est pas spécifié) en passant par des #GET et #SET a la place des doublons. Je ne cache pas que cela complexifie notablement l'écriture, donc je ne l'expose pas ici, mais c'est possible."

Donc je suis un peu étonné qu'elles soient plafonnées à moins de 1000 articles sauf précautions spéciales.

Toute la question est la "il existe d'autres solutions, mais cela complexifie notablement l'écriture" ... après il faut savoir à qui est destiné SPIP

Mais bon je ne prétends pas avoir tout compris (loin de la), c'est juste mon analyse du moment qui dépasse le seul cas de SPIP-Contrib.

@+ NicolasR

13

nicolasriq@free.fr a écrit :

Cette boucle déjà est extrèmement couteuse.
(car
ça fait un nombre bien trop grand d'articles à parcourir)

<BOUCLE_motsiteszone(MOTS){id_mot=233}>
  <BOUCLE_siteszone(SITES){id_mot}>
   <BOUCLE_syndiczone(SYNDIC_ARTICLES){id_syndic}{doublons
zone}>
   </BOUCLE_syndiczone>
  </BOUCLE_siteszone>
</BOUCLE_motsiteszone>

"un trop grand nombre d'articles" ??? la je m'interroge.

Je remets la boucle car peut être que je n'ai pas compris, mais il me semble que la boucle stocke 'tous les articles SYNDIQUES des sites qui ont le mot clé 233'. Les sites, (j'ai peut être faux) sont les rss de l'emplacement de la contrib sur la zone. S'il y a 100 contribs * 10 commits, ça fait déjà 1000 articles non ? Et il y a peu de plugins avec 10 commits. (Cependant, je ne sais pas si SPIP garde la trace des anciens articles syndiqués)

Donc, ce n'est pas une boucle qui parcourre les articles de contrib lui-même. Elle me semble différente.

Un rapide comptage des NOT IN de la boucle que j'ai posté donne environ 6311 articles (dont 11 qui sont doublons, ça fait un compte rond de 6300 articles uniques).

Certes, ce n'est pas un chiffre astronomique, mais peut être que pour MySQL, cette selection est difficile à mettre en place. C'est pour cela que le JOIN sera peut être plus rapide, mais il restera toujours cette selection dans la requete par NOT IN. SPIP ne pourra pas faire des miracles dessus, même s'il optimise la génération du NOT IN, il restera la requete à traiter pour MySQL !

Maintenant, on peut difficilement comparer avec l'Huma, qui ont un serveur différent. Pour reprendre ton exemple amusant, sur la route, tu es bridé à 130km maximum... Si tu roulais sur un circuit ou prenais un avion, tu pourrais rouler plus vite, mais ce n'est pas le même prix ^^.

MM.

14

Je remets la boucle car peut être que je n'ai pas compris, mais il me
semble que la boucle stocke 'tous les articles SYNDIQUES des sites qui
ont le mot clé 233'.

ah oui tu as raison, j'avais oublié (apparté pour Ben : comme quoi ce genre de discussion n'est pas à faire à chaud sur irc) ... donc ok pour 6300

Certes, ce n'est pas un chiffre astronomique, mais peut être que pour
MySQL, cette selection est difficile à mettre en place. C'est pour cela
que le JOIN sera peut être plus rapide, mais il restera toujours cette
selection dans la requete par NOT IN. SPIP ne pourra pas faire des
miracles dessus, même s'il optimise la génération du NOT IN, il restera
la requete à traiter pour MySQL !

tu dois avoir raison, sauf que je ne comprends rien (ou plus feint de ne pas comprendre) ... par principe je *ne veux pas* comprendre ce genre d'arguments. Ce que j'apprécie probablement le plus dans SPIP c'est son langage de boucle qui justement m'évite (enfin presque) d'avoir à me préoccuper de cela.

Maintenant, on peut difficilement comparer avec l'Huma, qui ont un
serveur différent. Pour reprendre ton exemple amusant, sur la route, tu
es bridé à 130km maximum... Si tu roulais sur un circuit ou prenais un
avion, tu pourrais rouler plus vite, mais ce n'est pas le même prix ^^.

Certes, mais ce n'était pas le but de mon exemple qui voulait simplement dire qu'en fasse d'une contrainte (ici la limitation de vitesse) les techniciens avaient mis un moyen simple pour le commun des mortels de la gérer (ici un compteur trivial de vitesse devant les yeux). Je demande la même chose pour les boucles (pas qu'elles suppléent aux limites des serveurs).

@+ NicolasR

15

(ou plus feint de ne pas comprendre) = (ou plutôt feint de ne pas comprendre)
qu'en fasse d'une contrainte = qu'en face d'une contrainte

vous aviez corrigé vous même :wink:

@+ NicolasT

16

* nicolasriq@free.fr tapuscrivait, le 16/12/2007 18:09:

vous aviez corrigé vous même :wink:

Nous le feindrons :wink:

17

Je n'y crois pas trop: j'attends d'un serveur SQL qu'il remplace une écriture maladroite par une meilleure.
J'ai du le faire moi-même ici à cause de PG, ça a mis à jour qu'une ancienne optim était tombée, je l'ai remise, mais tout ça dépend de la qualitié du serveur SQL employé, qui change d'une version à l'autre (et pas toujours en bien).

Mais sur le fond, je suis d'accord avec Nicolas: c'est à SPIP de repérer quand il produit des trucs trop lourds et de les optimiser.
Le premier compilateur de SPIP ne faisait aucune optimisation, le nouveau ne fait que des optimisations dites locales (produire au mieux le critère en cours d'analyse) jamais d'optimisations globales (voir que 2 critères ont des calculs en communs et ne les faire qu'une fois). Il y a a priori une mine d'optimisations là. Mais c'est du taff, et qui exige de l'expertise, d'ailleurs payée cher dans les abominables milieux qui n'utilisent pas SPIP: c'est pas trivial et ça demande du temps.

Committo,Ergo:Sum

18

Renato Formato ha scritto:

Matthieu Marcillaud ha scritto:
> La (et les) requetes proviennent de ça :

[(#REM) Suivi des seuls commits de la Zone syndiques sur Contrib - via usage du critere antidoublons ]
<BOUCLE_motsiteszone(MOTS){id_mot=233}>
                 <BOUCLE_siteszone(SITES){id_mot}><BOUCLE_syndiczone(SYNDIC_ARTICLES){id_syndic}{doublons zone}></BOUCLE_syndiczone></BOUCLE_siteszone>
</BOUCLE_motsiteszone>

Et de l'utilisation ensuite de {doublons zone} et {!doublons zone} dans d'autres boucles.

Cette boucle déjà est extrèmement couteuse.
Une suggestion est de syndiquer directement la 'zone' et non pas simplement toutes les contributions qui ont une entrée dans la zone (car ça fait un nombre bien trop grand d'articles à parcourir)

Ca allègerait un gros poids.

Sinon, il y a aussi #SET et #GET qui pourraient être empolyés à la place de {doublons} ici.

J'ai pas teste, mais quelque chose comme ça peut améliorer:

http://spip.pastebin.com/m4e096218

J'ai utilise array_push car la version SPIP de contrib a pas de filtre push.

Renato

Est que on peut tester ça ?
Je pense ça va aider pas mal.

Comment on fait, je commit et apres on met a jour sur spip-contrib ou il faut attendre le site de test?

Renato

19

La situation s'est particulièrement dégradée cette année : on est victime de
notre succès ?
Diagramme de cette semaine : http://tinyurl.com/2kbl3k
Résumé pour l'année 2007 : http://tinyurl.com/3ykjjf
Résumé pour l'année 2006 : http://tinyurl.com/2ups2m

Au delà du temps de réponse, j'y retiens un taux d'indisponibilité de 5 à
8%, c'est monstreux :((

Tiens tiens, ton autre post sur contrib me fait penser à ce mail .
Cela va mieux docteur ? :wink:

Ben.