Bonjour,
Pour info, un message d'un des admin d'ouvaton au sujet de SPIP : http://webnews.ouvaton.coop/article.php?id=20537&group=tech.aide#20537
« Et il y a egalement de probleme des nouvelles versions de spip qui sont EXTREMEMENT GOURMANDES. 120 sec pour afficher un 'petit' site sous spip n'est pas acceptable. Je pense que je vais opter pour une autre solution pour mes sites. »
Jacques
Jacques PYRAT wrote:
Bonjour,
Pour info, un message d'un des admin d'ouvaton au sujet de SPIP : http://webnews.ouvaton.coop/article.php?id=20537&group=tech.aide#20537
« Et il y a egalement de probleme des nouvelles versions de spip qui sont EXTREMEMENT GOURMANDES. 120 sec pour afficher un 'petit' site sous spip n'est pas acceptable. Je pense que je vais opter pour une autre solution pour mes sites. »
Jacques
spip-contrib (je ne parle même pas du spikini) est vraiment inutilisable ces jours ci effectivement.
Pierre
> Pour info, un message d'un des admin d'ouvaton au sujet de SPIP :
> http://webnews.ouvaton.coop/article.php?id=20537&group=tech.aide#20537
>
> « Et il y a egalement de probleme des nouvelles versions de spip qui
> sont EXTREMEMENT GOURMANDES. 120 sec pour afficher un 'petit' site sous
> spip n'est pas acceptable. Je pense que je vais opter pour une autre
> solution pour mes sites. »
Pour les problèmes de spikini j'avais remarqué qu'en supprimant le
include('inc-calcul.php3') [devenu inutile] on gagnait 5 secondes (ce qui
est ENORME). Or ce n'est que l'inclusion d'un fichier qui ne fait *rien*
d'autre que définir des fonctions.
En en parlant avec Nel, il semble que c'est parce que chaque fichier inclus
doit être appelé par le serveur web sur un serveur de fichiers, avant d'être
parsé ; le tout sans cache nulle part... j'ai suggéré l'installation de
php_acceleraotr ou équivalent. C'est vrai que SPIP inclut plein de fichiers,
mais bon, sur d'autres systèmes ça tourne très vite.
-- Fil
Fil a écrit :
En en parlant avec Nel, il semble que c'est parce que chaque fichier inclus
doit être appelé par le serveur web sur un serveur de fichiers, avant d'être
parsé ; le tout sans cache nulle part... j'ai suggéré l'installation de
php_acceleraotr ou équivalent. C'est vrai que SPIP inclut plein de fichiers,
mais bon, sur d'autres systèmes ça tourne très vite.
C'est curieux comme architecture.
Pourquoi pas un rsync des fichiers du serveur de fichier sur la ferme de serveurs web ?
Jacques
- parce qu'il faudrait beaucoup plus de disque sur chaque machine
- parce que quand tu modifies une page par ftp, il faudrait relancer le
rsync dans la foulée pour que ça apparaisse partout
- parce que quand tu génères un fichier depuis php, c'est en local et
qu'il faudrait alors le propager sur les autres machines (écriture du
inc_connect lors de l'install spip par exemple)
- parce qu'avec un réseau dédié et un bon filer, ça va aussi vite qu'un
disque local pour beaucoup moins d'emmerdes
- surement plein d'autres raisons qui font que la majorité des
hébergeurs font comme ça 
C'est curieux comme architecture.
Plutôt courant, au contraire...
Pourquoi pas un rsync des fichiers du serveur de fichier sur la ferme de serveurs web ?
Tout simplement parce que rsync permet de synchroniser, ce qui donc suppose qu'on a toujours un différentiel potentiel (et plein de soucis qui vont avec), alors qu'avec un serveur de fichiers unique, on est sûr d'avoir la même chose pour tout le monde, non ?
-Nicolas
Pour les problèmes de spikini j'avais remarqué qu'en supprimant le
include('inc-calcul.php3') [devenu inutile] on gagnait 5 secondes (ce qui
est ENORME). Or ce n'est que l'inclusion d'un fichier qui ne fait *rien*
d'autre que définir des fonctions.
et qui inclut une tétrachiée d'autres bidules :
<extrait>
include_ecrire("inc_meta.php3");
include_ecrire("inc_index.php3");
include_ecrire("inc_texte.php3");
include_ecrire("inc_filtres.php3");
include_ecrire("inc_lang.php3");
include_ecrire("inc_documents.php3");
include_ecrire("inc_abstract_sql.php3");
include_ecrire("inc_forum.php3");
include_ecrire("inc_debug_sql.php3");
include_local("inc-calcul-outils.php3");
// NB: Ce fichier peut initialiser $dossier_squelettes (old-style)
if ($f = find_in_path("mes_fonctions.php3"))
include_local ($f);
// Gestionnaire d'URLs
if (@file_exists("inc-urls.php3"))
include_local("inc-urls.php3");
else
include_local("inc-urls-".$GLOBALS['type_urls'].".php3");
</extrait>
En en parlant avec Nel, il semble que c'est parce que chaque fichier inclus
doit être appelé par le serveur web sur un serveur de fichiers, avant d'être
parsé ; le tout sans cache nulle part...
Le noyau du système a forcément un joli cache pour éviter de taper la
machine distante à chaque appel de fichier.
C'est PHP qui rame, on le sait depuis longtemps, mais normalement du
soin devrait être accordé aux fichiers inclus.
j'ai suggéré l'installation de
php_acceleraotr ou équivalent.
La dernière fois que j'ai regardé, la page de php-eaccelerator disait
clairement que le soft n'est pas stable. C'est vrai que c'est la
solution la plus agréable et la plus générale.
C'est vrai que SPIP inclut plein de fichiers,
mais bon, sur d'autres systèmes ça tourne très vite.
Comme n'importe quel logiciel, ça tourne plus vite sur des systèmes plus
rapides et moins chargés 
Ouvaton devrait essayer de mettre un proxy-cache en "frontal" (mod_cache
par exemple).
Ben, pas si elles gèrent bien les en-têtes liés à la mise en cache. Ca
ne fout pas plus la zone que sur le proxy de ton FAI...