"Votre site est de très loin le plus gros consommateur du serveur, pour seulement 3500 visiteurs quotidien, les 2 suivants sont à 15000...
Du coup, il dépasse les limites de sécurité du serveur (qui ne sont pas là pour vous limiter, mais pour éviter de planter le serveur). C'est efficace, les autres sites n'en pâtissent pas, mais le vôtre si bien sûr.
C'est dû au tristement célèbre plugin "couteau suisse" de SPIP."
Il me recommande ensuite de remettre en place Expresso
que j'avais installé en V192 mais avais supprimé lors du passage à spip 200
car ça me semblait trop risqué comme technologie de triturer le htaccess.
Dans le couteau suisse sont activées les lames suivantes :
- Ancres douces
- SPIP et les liens… externes
- Supprime le numéro
- Visiteurs connectés
- Balise #INSERT_HEAD
et
- Un sommaire automatique dont je ne souhaite pas me passer
et que je ne saurais pas remplacer
Qu'est-ce donc qui serait pénalisant dans tout cela ?
Une lame ou bien le manche en lui-même ?
Le CS est sensé ne mettre en branle php QUE pour les lames utilisées.
Cela voudrait dire que je ne peux pas améliorer
en implémentant ces fonctionnalités assez basiques à la main, sans CS ?
"Votre site est de très loin le plus gros consommateur du serveur, pour seulement 3500 visiteurs quotidien, les 2 suivants sont à 15000...
Du coup, il dépasse les limites de sécurité du serveur (qui ne sont pas là pour vous limiter, mais pour éviter de planter le serveur). C'est efficace, les autres sites n'en pâtissent pas, mais le vôtre si bien sûr.
C'est dû au tristement célèbre plugin "couteau suisse" de SPIP."
...
Qu'est-ce donc qui serait pénalisant dans tout cela ?
Une lame ou bien le manche en lui-même ?
"Votre site est de très loin le plus gros consommateur du serveur, pour seulement 3500 visiteurs quotidien, les 2 suivants sont à 15000...
Du coup, il dépasse les limites de sécurité du serveur (qui ne sont pas là pour vous limiter, mais pour éviter de planter le serveur). C'est efficace, les autres sites n'en pâtissent pas, mais le vôtre si bien sûr.
C'est dû au tristement célèbre plugin "couteau suisse" de SPIP."
...
Qu'est-ce donc qui serait pénalisant dans tout cela ?
Une lame ou bien le manche en lui-même ?
non, je ne trollerai pas ...
Moi non plus !
Mais est-ce que si je désactive le CS
et que je remplace chaque lame par son équivalent,
j'aurais significativement allégé le fonctionnement du site ?
"Votre site est de très loin le plus gros consommateur du serveur, pour seulement 3500 visiteurs quotidien, les 2 suivants sont à 15000...
Ça serait peut-être l'occasion de tester les évolutions proposées par Cerdic sur la branche 2 (indépendamment du CS dont je me retiendrais aussi de dire quoique ce soit, n'ayant pas testé pour ma part).
"Votre site est de très loin le plus gros consommateur du serveur, pour seulement 3500 visiteurs quotidien, les 2 suivants sont à 15000...
Du coup, il dépasse les limites de sécurité du serveur (qui ne sont pas là pour vous limiter, mais pour éviter de planter le serveur). C'est efficace, les autres sites n'en pâtissent pas, mais le vôtre si bien sûr.
C'est dû au tristement célèbre plugin "couteau suisse" de SPIP."
...
Qu'est-ce donc qui serait pénalisant dans tout cela ?
Une lame ou bien le manche en lui-même ?
non, je ne trollerai pas ...
Moi non plus !
Mais est-ce que si je désactive le CS
et en cherchant deja si c'est pas une lame en particulier, genre utilisateurs connectés ?
il n'y a à priori que lui qui ajoute du traitement à chaque hit, pour le reste, le fait d'utiliser CS mange sans doute un peu plus de RAM, mais ne devrait ajouter du traitement qu'au calcul du cache (ou j'ai raté un episode ?)
"Votre site est de très loin le plus gros consommateur du serveur, pour seulement 3500 visiteurs quotidien, les 2 suivants sont à 15000...
Ça serait peut-être l'occasion de tester les évolutions proposées par Cerdic sur la branche 2 (indépendamment du CS dont je me retiendrais aussi de dire quoique ce soit, n'ayant pas testé pour ma part).
J'ai abandonné Expresso en raison des risques avec le htaccess,
alors je n'ai pas envie de passer en SVN...
L'hébergeur a depuis complèté son analyse :
"je viens de voir que vous êtes encore en PHP 4... donc vous ne bénéficiez pas de toutes les améliorations de PHP5, en particulier le "realpath cache", qui permet de réduire le nombre de lstat() produits par le PHP à chaque include (et donc très utilisés par les plugins). Les interpréteurs PHP de votre site passe 91% de leur temps à faire des lstat !!!
En passant en PHP5, le gain devrait être très important !"
Ce qui n'est pas sans rapport avec les travaux de Cerdic il me semble
- voire même les doublonne mais je dois mal comprendre -.
Matthieu Marcillaud a écrit :
L'hébergeur a depuis complèté son analyse :
"je viens de voir que vous êtes encore en PHP 4... donc vous ne bénéficiez pas de toutes les améliorations de PHP5, en particulier le "realpath cache", qui permet de réduire le nombre de lstat() produits par le PHP à chaque include (et donc très utilisés par les plugins). Les interpréteurs PHP de votre site passe 91% de leur temps à faire des lstat !!!
En passant en PHP5, le gain devrait être très important !"
Ce qui n'est pas sans rapport avec les travaux de Cerdic il me semble
Exactement, mais pas que : la réduction des include_once aussi devrait aider.
C'est vraiment intéressant d'avoir un hébergeur qui fait des analyses précises… il serait bienvenu de tester la svn branche 2.0 sur ton site, en partenariat avec ton hébergeur, voir si les propositions de Cédric tiennent la route. Enfin, tu fais ce que tu veux. Pouvoir accéder à certaines données brutes, avant/après les changements introduits par Cédric pour voir les gains/pertes produits aussi. Perso je ne m'y connais pas du tout, mais d'autres sur la liste si.
Le 24 nov. 2009 à 17:29, Matthieu Marcillaud a écrit :
Les interpréteurs PHP de votre site passe 91% de leur temps à faire des lstat
ah oui quand même ...
Mais vu ce que j'ai enlevé ça n'est pas si étonnant que ça :
- de l'ordre de 1000 include_once sur un chemin relatif
- de l'odre de 1500 file_exists
Donc oui, le passage à PHP5 améliorera nettement les choses.
Et oui, le passage à la prochaine version stable sera encore un plus.
non, ça c'est la dernière version stable publiée, donc la 2.0.10
Ben ça n'a pas de sens puisqu'il y a un dossier "stable" à la racine, qui correspond à la dernière stable publiée justement.
Mon lien est dans le dossier "dev" donc il n'a aucune raison de pointer sur un tag de la dernière stable. Mais bien sur la dernière version existante de la branche svn stable.
Si ce n'est pas le cas, je trouve que c'est un bug du générateur de paquet.
non, ça c'est la dernière version stable publiée, donc la 2.0.10
si si c'est bien ça : c'est la branche 2.0 qui est construite tous les
jours ( quand il
y a quelque chose à se mettre sous la dent)
là c'est bien la 14764
non, ça c'est la dernière version stable publiée, donc la 2.0.10
si si c'est bien ça : c'est la branche 2.0 qui est construite tous les
jours ( quand il
y a quelque chose à se mettre sous la dent)
là c'est bien la 14764
Apparament le couteau suisse n'y est pas pour grand chose
donc je change le titre pour enterrer le troll
(mais il est probablement encore vivant...)
Matthieu Marcillaud a écrit :
C'est vraiment intéressant d'avoir un hébergeur qui fait des analyses précises… il serait bienvenu de tester la svn branche 2.0 sur ton site, en partenariat avec ton hébergeur, voir si les propositions de Cédric tiennent la route. Enfin, tu fais ce que tu veux. Pouvoir accéder à certaines données brutes, avant/après les changements introduits par Cédric pour voir les gains/pertes produits aussi.
Ok, J'ai demandé à l'hébergeur et obtenu "exceptionnellement"
et pour ce besoin précis de mise au point et retour vers l'équipe spip
un accés ssh spécifique qui permettra de
<quote>faire un "top" pour vous montrer les interpr�teurs PHP de votre compte,
Relevez leur PID dans la premi�re colonne, faites q pour quitter top,
et tapez "strace -c -p PID" pour tracer les appels syst�mes
de l'interpr�teur PHP concern�, jusqu'� que vous fassiez "Ctrl C"</quote>
Je ferai les mesures et comparaisons ce jeudi matin.
Le passage PHP4/PHP5 en tout cas,
puis le passage à la 2.0.11SVN si ça se passe bien et si il reste du temps.
Je ne connais pas du tout les outils top et strace recommandés alors
peut être je demanderai de l'aide sur IRC.
Pardon pour ce silence momentané dû à une hospitalisation imprévue, et surtout pour mon invitation à un débat aujourd'hui un peu ancien.
Dans la liste des lames activées, aucune n'est consommatrice de ressources serveur importantes si ce n'est le sommaire automatique qui effectue un traitement non négligeable sur le texte des articles au moment du calcul de la page avant la mise en cache.
Le CS compile les lames actives et réduit au maximum son impact lors de la vie normale du site. Le poids du fichier public de langue est minime et les quelques tests réalisés à chaque hit se font essentiellement sur la table des metas de spip, les paramètres d'url et l'inclusion des deux fichiers d'options précompilés.
Une étude approfondie serait peut-être nécessaire afin d'optimiser davantage le code actuel, ça on le peut toujours.
Il est clair que les lames sont très inégales en terme de performance et leur activation doit être raisonnée sur les serveurs les plus fragiles.
Pat
JLuc a écrit :
Dans le couteau suisse sont activées les lames suivantes :
- Ancres douces
- SPIP et les liens… externes
- Supprime le numéro
- Visiteurs connectés
- Balise #INSERT_HEAD
et
- Un sommaire automatique dont je ne souhaite pas me passer
et que je ne saurais pas remplacer
Qu'est-ce donc qui serait pénalisant dans tout cela ?
Une lame ou bien le manche en lui-même ?
Le CS est sensé ne mettre en branle php QUE pour les lames utilisées.
Cela voudrait dire que je ne peux pas améliorer
en implémentant ces fonctionnalités assez basiques à la main, sans CS ?
Ne serait-il pas envisageable de sortir certaines lames en plugins autonomes?... En fait surtout les lames de fonctions majeures...
Cela permettrait d'alléger un peu le couteau suisse...
<troll>
Aujourd'hui le record du couteau suisse est de 87 outils et 141 fonctions... Ce qui donne un peu ça :
Ça fait un peu beaucoup non?
</troll>
Le but de ce découpage est l'allégement du code de CS et peut-être lui permettre de prendre moins de ressources si cela s'avère vrai...
Cordialement,
Teddy
Le 2 déc. 09 à 22:39, Pat a écrit :
Salut à tous,
Pardon pour ce silence momentané dû à une hospitalisation imprévue, et surtout pour mon invitation à un débat aujourd'hui un peu ancien.
Dans la liste des lames activées, aucune n'est consommatrice de ressources serveur importantes si ce n'est le sommaire automatique qui effectue un traitement non négligeable sur le texte des articles au moment du calcul de la page avant la mise en cache.
Le CS compile les lames actives et réduit au maximum son impact lors de la vie normale du site. Le poids du fichier public de langue est minime et les quelques tests réalisés à chaque hit se font essentiellement sur la table des metas de spip, les paramètres d'url et l'inclusion des deux fichiers d'options précompilés.
Une étude approfondie serait peut-être nécessaire afin d'optimiser davantage le code actuel, ça on le peut toujours.
Il est clair que les lames sont très inégales en terme de performance et leur activation doit être raisonnée sur les serveurs les plus fragiles.
Pat
JLuc a écrit :
Dans le couteau suisse sont activées les lames suivantes :
- Ancres douces
- SPIP et les liens… externes
- Supprime le numéro
- Visiteurs connectés
- Balise #INSERT_HEAD
et
- Un sommaire automatique dont je ne souhaite pas me passer
et que je ne saurais pas remplacer
Qu'est-ce donc qui serait pénalisant dans tout cela ?
Une lame ou bien le manche en lui-même ?
Le CS est sensé ne mettre en branle php QUE pour les lames utilisées.
Cela voudrait dire que je ne peux pas améliorer
en implémentant ces fonctionnalités assez basiques à la main, sans CS ?
JLuc
Le 2 décembre 2009 23:08, Fil <fil@rezo.net> a écrit :
lui permettre de prendre moins de ressources si cela s'avère vrai...
oui sauf que ça reste une rumeur infondée... d'où le topic de cette discussion
-- Fil
D'un autre coté , la mise en place de plugin me semble beaucoup plus
simple aujourd'hui (depuis spip 2.0) que lors de la sortie de CS.
CS offre aussi la possibilité d'ajouter des lames à son manche de
façon facilité. C'était peut être nécessaire précedemment, peut être
moins aujourd'hui ?
Est ce que Spip y gagnerait en facilité de paramétrage ? Je le pense,
je peut me tromper.