J'ai remarqué, sur certains hébergeurs, que l'affichage de spip était vraiment très très lent ... Par exemple, sur celui-ci : http://www.leparisdedorothee.com
Alors que, lorsque je vais sur spip-contrib ou spip-plugins.net, ça va à toute vitesse !
J'aimerais savoir pourquoi il peut y avoir tant de différences : est-ce dû à spip, à des plugins, ou à des squelettes que j'aurais mal exploités ? Comment déterminer les causes de la lenteur ?
Merci de me donner une piste, si c'est possible.
Hum,
on dirait un mail plutôt pour spip-user que spip-dev.
il y a plein de raisons (ton serveur est pas aussi rapide, la connection internet est pas aussi large, etc.) mais généralement, c'est une histoire de cache et de visiteurs.
Sur spip.net, spip-contrib and co. il y a beaucoup de visiteurs et les delais de cache ne sont pas trop rapide, donc:
- il n'y a pas trop souvent de recalcul du cache
- c'est pas toujours le même utilisateur qui se retrouve à faire les requettes qui recalcul le cache
le cache est calculé au minimum toute les Xs spécifié par le delais du squelette. Mais en fait, il n'est recalculé que quand il y a un visiteur qui demande le cache. Donc, si tu as un délais de 1 jour sur une page, que le visiteur Bob la visite une fois, personne ne la visite et puis Bob revient voir la page 1 semaine après, alors c'est encore Bob qui se tappe le recalcul du cache. si 10 visiteurs sont passé avant Bob et qu'un est venu moins d'un jour avant... alors Bob n'aura pas le delais du recalcul mais aura la page direct du cache.
Pierre
Marc VALLETEAU de MOULLIAC wrote:
Je dirais que c'est sûrement dû a un peu de tout sûrement, à part spip car c'est le même pour tout le monde !
-* les plugins :
-** certains sont optimisés, d'autres peuvent faire ramer un site, il faut bien les choisir (non je ne balancerai pas ...). En règle général, n'activer que les plugins réellement utiles...
-** il y a des outils comme zend studio qui permettent de profiler le code et de mesurer le temps passé dans chaque fonction à chaque hit. Pour debusquer les loups c'est très utile.
-* le squelette :
-** certains assemblages de boucles peuvent être tres lents, d'autre optimisés. Même si le compilateur fait de son mieux pour optimiser, il reste moins efficace qu'un humain obstiné. Sur la home de contrib il y avait par exemple 3 requêtes sur 200 qui consommaient plus de la moitié du temps de calcul de la page. Pour voir les requêtes lentes, rien de tel que
?var_mode=calcul&var_profile=1
-** s'assurer qu'une page en cache est bien servie sans requête sql est évidemment promordial si on ne sait pas trop ce que l'on a mis dans son site (plugins et squelettes)
-* le serveur : il y a plein de variantes de configuration. Les hebergement mutualises utilisent un filer qui est pénalisant en performance. Les hébergements dédiés sont livrés dans des configurations par défaut plutôt orientées sécurité que vitesse... Un bon cacheur d'opcode (eaccelerator, xcache) permet d'améliorer bien des problèmes
Pour avoir fait un peu d'optimisation sur des site lents il n'est pas rare de pouvoir gagner un coeff 3 à 5 sur le temps de calcul des pages en chassant les lests embarqués rien que sur les squelettes et les plugins.
Quand au serveur, pour prendre l'exemple d'un gros hebergeur francais, entre la config par defaut et une config optimisée, on peut mesurer un gain de perfo de l'ordre de 4 sur le temps de service d'une page en cache.
En conclusion, la vitesse d'un site spip (et de tout site web dynamique plus généralement) est la combinaison de beaucoup de facteurs qu'il faut maitriser, et cela peut varier de manière importante pour le même résultat en fonction des optimisations que l'on aura pu et su faire ou non.
Pour ce qui est de spip-contrib, il s'agit actuellement d'un serveur dédié entrée de gamme double coeur, mais sur lequel la config serveur apache/php a été optimisée avec un cacheur d'opcode (XCache), et le squelette a été optimisé par rapport à la version précédente pour les boucles les plus gourmandes.
Dans ces conditions il sert environ 5000visites/jour sans trop de problème.
Cédric
cedric.morin@yterium.com a écrit :
-** s'assurer qu'une page en cache est bien servie sans requête sql est évidemment promordial si on ne sait pas trop ce que l'on a mis dans son site (plugins et squelettes)
Y a t il un moyen de faire ça à part
interrompre l'accés à MySQL et voir si le site est toujours ok
ou décortiquer le code des squelettes ?
Un mode debug ou var_profile=&calcul=no existe t il ?
JLuc
le fait meme d'etre connecté en temps qu'admin sur le site et d'avoir les boutons d'admin sur la page provoque au moins une requête sql : c'est donc intrusif et empeche toute vérification de ce type.
Pour ma part j'utilise zend studio qui permet d'avoir la liste des fonctions et fichiers chargés sur un hit et de vérifier qu'un hit anonyme en cache est bien sans requete sql.
Il faudrait sinon avoir un mécanisme du type
?var_mode=trace
qui logerait toutes les inclusions sur ce hit, à condition que ce soit autorisé par un
define('_VAR_MODE_TRACE',1);
dans mes options
(puisque pas question de se reposer sur l'authentification de l'admin, et hors de question aussi de laisser ce mode libre car il pourrait être utilisé pour une attaque DOS)
Cédric
Merci de ces remarques ... J'ai posté sur cette liste, car je me demande si je n'ai pas plutôt un pb par rapport au développement que simplement user ...
Je suspecte plusieurs choses :
1. le site en question (http://www.leparisdedorothee.com) est en deux langues, gérées par des mots-clés sur les rubriques et autres objets. J'ai sur la page sommaire une dizaine de boucles (y compris les INCLURE) avec des critères de sélection sur des mots-clefs ou des groupes de mots ... Peut-être est-ce un critère de ralentissement ?
2. J'utilise la syntaxe <INCLURE{}> plutôt que [(#INCLURE{})] : cela peut-il créer une différence ?
3. J'ai laissé le cache standard de la dist de spip : il est certainement trop court ? Je vais essayer de mettre 432000 (5 jours) sur la page sommaire et dans les pages incluses, ça devrait déjà arranger un peu, non ? Il s'agit d'une agence immobilière dont les affichages changent très peu ...
4. J'ai mis pas mal de plugins en action : cfg (naturellement), couteau suisse, Envoyer par mail (enviar_email), deux autres plugins que j'ai faits sur le modèle de enviar_email, Imprimer document (imrimir_documento), spip_listes et Thckbox2. Y aurait-il un de ceux-ci qui pourrait être en cause ?
5. Je suis sur une 192d, peut-être des améliorations avec 192e ?
6. Je suis passé pratiquement directement d'une 1.6 à une 192d, peut-être que la base de données en aurait souffert ? Mais est-elle réellement en cause ?
7. Le site est hébergé chez sivit. Les tests que j'avais faits auparavant en ligne étaient sur le site installé chez mon hébergeur (aquaray) et là, il n'y a aucun problème de rapidité ... Par ailleurs, chez sivit, la navigation dans la partie privée est, aussi, très lente, or je n'ai rien touché à ce niveau ...
Bon, voilà mes quelques réflexions. Je me dis vraiment qu'il faut que je creuse vraiment les méthodes d'optimisation à ce niveau ...
a+
J'ai remarqué, sur certains hébergeurs, que l'affichage de spip était vraiment très très lent ... Par exemple, sur celui-ci : http://www.leparisdedorothee.com
Alors que, lorsque je vais sur spip-contrib ou spip-plugins.net, ça va à toute vitesse !
J'aimerais savoir pourquoi il peut y avoir tant de différences : est-ce dû à spip, à des plugins, ou à des squelettes que j'aurais mal exploités ? Comment déterminer les causes de la lenteur ?
Je dirais que c'est sûrement dû a un peu de tout sûrement, à part spip car c'est le même pour tout le monde !
-* les plugins :
-** certains sont optimisés, d'autres peuvent faire ramer un site, il faut bien les choisir (non je ne balancerai pas ...). En règle général, n'activer que les plugins réellement utiles...
Voici ce que j'ai installé : cfg (naturellement), couteau suisse, Envoyer par mail (enviar_email), deux autres plugins que j'ai faits sur le modèle de enviar_email, Imprimer document (imrimir_documento), spip_listes et Thckbox2. Y aurait-il un de ceux-ci qui pourrait être en cause ?
-** il y a des outils comme zend studio qui permettent de profiler le code et de mesurer le temps passé dans chaque fonction à chaque hit. Pour debusquer les loups c'est très utile.
zend studio fonctionne-t-il sur Mac osX ?
-* le squelette :
-** certains assemblages de boucles peuvent être tres lents, d'autre optimisés. Même si le compilateur fait de son mieux pour optimiser, il reste moins efficace qu'un humain obstiné. Sur la home de contrib il y avait par exemple 3 requêtes sur 200 qui consommaient plus de la moitié du temps de calcul de la page. Pour voir les requêtes lentes, rien de tel que
?var_mode=calcul&var_profile=1
J'ai fait cela (en local, en ligne, ne fonctionne pas ...) et j'ai des durée variant de 0,012 à 0,045 par requête, qu'en penses-tu ?
-** s'assurer qu'une page en cache est bien servie sans requête sql est évidemment promordial si on ne sait pas trop ce que l'on a mis dans son site (plugins et squelettes)
Comment voir cela ?
-* le serveur : il y a plein de variantes de configuration. Les hebergement mutualises utilisent un filer qui est pénalisant en performance. Les hébergements dédiés sont livrés dans des configurations par défaut plutôt orientées sécurité que vitesse...
Le site est hébergé chez sivit. Les tests que j'avais faits auparavant en ligne étaient sur le site installé chez mon hébergeur (aquaray) et là, il n'y a aucun problème de rapidité ... Par ailleurs, chez sivit, la navigation dans la partie privée est, aussi, très lente, or je n'ai rien touché à ce niveau ...
Un bon cacheur d'opcode (eaccelerator, xcache) permet d'améliorer bien des problèmes
A mettre sur un site mutualisé, ou uniquement sur site dédié ?
Pour avoir fait un peu d'optimisation sur des site lents il n'est pas rare de pouvoir gagner un coeff 3 à 5 sur le temps de calcul des pages en chassant les lests embarqués rien que sur les squelettes et les plugins.
J'espère que mes compétences me permettront de m'y mettre : à ton avis, où trouver de l'info ou de l'aide sur le sujet ?
Quand au serveur, pour prendre l'exemple d'un gros hebergeur francais, entre la config par defaut et une config optimisée, on peut mesurer un gain de perfo de l'ordre de 4 sur le temps de service d'une page en cache.
En fait d'optimisation, je suppose qu'il faut voir ça avec l'hébergeur ? Est-ce qu'une gestion d'url propres pourrait aider dans le fonctionnement, aussi ?
Merci Cédric de ces conseils ... Je me dis vraiment qu'il faut que je creuse vraiment les méthodes d'optimisation à ce niveau ...
A+
Marc
Merci de ces remarques ... J'ai posté sur cette liste, car je me demande si
je n'ai pas plutôt un pb par rapport au développement que simplement user
...Je suspecte plusieurs choses :
1. le site en question (http://www.leparisdedorothee.com) est en deux
langues, gérées par des mots-clés sur les rubriques et autres objets. J'ai
sur la page sommaire une dizaine de boucles (y compris les INCLURE) avec des
critères de sélection sur des mots-clefs ou des groupes de mots ...
Peut-être est-ce un critère de ralentissement ?
si tu utilises titre_mot par exemple, ça allourdit pas mal les
boucles, mais ça ne veut pas dire qu'il ne faut pas l'utiliser 
Il faut bien penser comment tu fais les boucles, s'il n'y a pas moyen
de faire une boucle sur moins d'éléments dès le départ (en particulier
quand tu joins les articles et les mots) etc.
Ensuite, il faut découper le squelette en INCLURE le plus possible et
bien penser les delais de chaque inclure, il y a certainement des
bouts de pages qui ont besoin d'être recalculés souvent quand d'autre
n'ont presque jamais besoin de recalcul (entete, etc.)
2. J'utilise la syntaxe <INCLURE{}> plutôt que [(#INCLURE{})] : cela peut-il
créer une différence ?
<INCLURE> permet d'avoir un cache séparé du squelette principale, ce
qui te permet d'avoir un delais de recalcul différent. S'il n'y a pas
besoin d'un délais différent mais que l'inclure est surtout pour
simplifier le codage (reutilisation, etc.), alors tu peux utilise
#INCLURE.
3. J'ai laissé le cache standard de la dist de spip : il est certainement
trop court ? Je vais essayer de mettre 432000 (5 jours) sur la page sommaire
et dans les pages incluses, ça devrait déjà arranger un peu, non ? Il s'agit
d'une agence immobilière dont les affichages changent très peu ...
tu peux écrire les délais dans les squelettes: #CACHE{5*24*3600}, ça
permet de plus facilement comprendre ce que le delais veut vraiment
dire
pour la valeur à utiliser, comme je disais avant, ça dépend de quelle
partie du squelette. L'entete va probablement peu changer, alors
qu'une boucle qui liste les annonces changera plus souvent...
Pierre
Merci Pierre, je vais pouvoir reprendre pas mal de réflexion sur mon code, en me basant sur tes remarques ... Ce qui me manque, c'est un "vrai" outil de mesure du temps pris par une boucle. J'ai testé var_mod=calcul&var_profile=1, mais ça marche uniquement en local, non ?
Et oui, j'utilise beaucoup (sur ce site) titre_mot. Ce serait mieux de le remplacer par id_mot, à ton avis ?
Merci Pierre, je vais pouvoir reprendre pas mal de réflexion sur mon code,
en me basant sur tes remarques ... Ce qui me manque, c'est un "vrai" outil
de mesure du temps pris par une boucle. J'ai testé
var_mod=calcul&var_profile=1, mais ça marche uniquement en local, non ?
non, mais il faut être loggué
Et oui, j'utilise beaucoup (sur ce site) titre_mot. Ce serait mieux de le
remplacer par id_mot, à ton avis ?
he bien, comme je disais, j'ai rien contre titre_mot, mais pour
l'utiliser, il faut joindre la liste des articles avec la liste des
mots clefs, puis cherché les articles qui ont ce mot clef, s'il y a
beaucoup d'articles et de mots clefs, alors ça peut faire une requette
un peu lourde.
id_mot est à peut pret pareil sauf que tu cherches sur un id, donc
c'est un tantinet plus rapide pour sql.
Il faut donc faire attention quand tu l'utilises de le faire sur des
boucles articles qui retournent peu de résultats ou de le faire de
façon un peu intelligente si tu peux pas réduire le nombre d'articles
à chercher (i.e. le découper en boucles, le passer dans un inclure,
etc.).
Pierre
Merci Pierre, je vais pouvoir reprendre pas mal de réflexion sur mon code,
en me basant sur tes remarques ... Ce qui me manque, c'est un "vrai" outil
de mesure du temps pris par une boucle. J'ai testé
var_mod=calcul&var_profile=1, mais ça marche uniquement en local, non ?non, mais il faut être loggué
Et oui, j'utilise beaucoup (sur ce site) titre_mot. Ce serait mieux de le
remplacer par id_mot, à ton avis ?he bien, comme je disais, j'ai rien contre titre_mot, mais pour
l'utiliser, il faut joindre la liste des articles avec la liste des
mots clefs, puis cherché les articles qui ont ce mot clef, s'il y a
beaucoup d'articles et de mots clefs, alors ça peut faire une requette
un peu lourde.
eh bien, j'ai examiné ma page sommaire avec attention et, en fait, je n'ai aucune requête articles à partir de titre_mot, c'est uniquement sur rubriques et breves, sachant qu'il y a 5 rubriques (par langue) et une dizaine de brèves. Alors, je ne pense vraiment pas que la lenteur vienne de là (mais je peux me tromper, non ?).
id_mot est à peut pret pareil sauf que tu cherches sur un id, donc
c'est un tantinet plus rapide pour sql.
Oui, sur de l'entier, ça va en principe plus vite.
Il faut donc faire attention quand tu l'utilises de le faire sur des
boucles articles qui retournent peu de résultats ou de le faire de
façon un peu intelligente si tu peux pas réduire le nombre d'articles
à chercher (i.e. le découper en boucles, le passer dans un inclure,
etc.).
Par contre, j'utilise id_mot en critères de boucles (parfois trois id_lots) dans des articles pour sélectionner des articles selon ce mot-clés. Et ces pages s'affichent en général plus vite que la page sommaire !! Bizarre, non ?
Je crois que je vais essayer de voir si l'hébergeur ne serait pas un peu (beaucoup ?) en cause aussi ...
Marc
Marc VALLETEAU de MOULLIAC wrote:
J'ai remarqué, sur certains hébergeurs, que l'affichage de spip était vraiment très très lent ...
Notre site tourne avec un SPIP 2 beta qui commence à dater un peu (r12526).
J'ai fait l'essai avec et sans cette ligne dans mes_options.php :
$derniere_modif_invalide = false;
Résultat : le site tourne sensiblement plus vite lorsque cette ligne est présente. (Sensible, je veux dire pour le visiteur.)
Je pense qu'il y a eu du travail sur le cache depuis ma dernière mise à jour, ce test n'est peut-être pas valable pour les toutes nouvelles versions de SPIP.
Paolo
Marc VALLETEAU de MOULLIAC a écrit :
-* les plugins :
-** certains sont optimisés, d'autres peuvent faire ramer un site, il faut bien les choisir (non je ne balancerai pas ...). En règle général, n'activer que les plugins réellement utiles...Voici ce que j'ai installé : cfg (naturellement), couteau suisse, Envoyer par mail (enviar_email), deux autres plugins que j'ai faits sur le modèle de enviar_email, Imprimer document (imrimir_documento), spip_listes et Thckbox2. Y aurait-il un de ceux-ci qui pourrait être en cause ?
Donc, à propos du Couteau Suisse, certains outils sont plus couteux que d'autres. 2 exemples :
1. la gestion des variables de SPIP ne coute rien du tout
2. l'utilisation du glossaire prend autant de ressources serveur que les textes sont longs à examiner, mais ceci simplement au moment de la mise en cache par SPIP, donc une seule fois par jour en principe.
En fin de compte, il faut nous dire quelles lames tu utilises. Si l'une d'entre elle n'est pas optimisée, ben faut bosser dessus...
Pat
Merci pour votre soutien à tous 
Je pars en province pour accueillir mon tout récent petit-fils dans notre monde réel !! Aussi, ne serai-je plus sur la liste jusqu'à lundi prochain ... et je reprendrai mes investigations sur la vitesse de traitement de spip. En passant, j'ai encore un ou deux sites, chez des clients, qui sont en 1.8, et fouchtra, qu'ils vont vite !!
A+