J'ai installé SPIP 1.06 sur un serveur dédicacé (procédure manuelle qui
consiste à copier tous les fichiers).
Pour installer, je vais visiter l'adresse : http://www.monsite.com/ecrire
Au lieu de lancer l'installation, je vois seulement la liste des fichier de
ce répertoire.
J'ai également essayé de lancer : http://www.monsite.com/ecrire/index.php3
et là, le programme me propose de downloader le fichier index.php3, mais ne
l'exécute pas.
Je suppose qu'il s'agit d'une grosse bêtise facile à corriger pour qui
maîtrise ... mais ce n'est pas mon cas.
Merci d'avance pour votre aide.
Fichiers modifiés dans la beta9 : ecrire/inc.php3 et ecrire/inc_version.php3
- Tout d'abord, j'ai corrigé le bug sur les secteurs de brèves : ils
sont mis à jour à chaque modification de rubriques, comme pour les
articles.
- Surtout, une nouvelle fonctionnalité un peu expérimentale, qui est
en test sur le site du Diplo (!). Il s'agit d'une fonctionnalité de
PHP4 qui permet de générer automatiquement un flux compressé en sortie
quand le navigateur sait le décoder. Or, le HTML (et les textes qui y
sont imbriqués) se compresse très bien (avec gzip par exemple) : la
taille des données transférées est alors divisée par deux, trois voire
quatre.
Sur le Diplo, dont la bande passante saturait affreusement en début
d'après-midi à cause de la mise en ligne d'un dossier sur les attentats,
ça a permis apparemment de retrouver un site fluide, ce qui n'est pas
rien (Fil pourra éventuellement infirmer s'il y a d'autres paramètres).
Note : c'est bien la bande passante qui limitait, pas le CPU qui restait
assez frais.
Ainsi, on économise de la bande passante (bien pour le serveur et
pour éviter les saturations), et les chargements sont plus rapides
chez les visiteurs. Cette fonctionnalité est appliquée à l'espace
public mais aussi à l'espace privé (ça peut être utile, pour charger
plus vite les forums de validation qui s'éternisent :-)).
Par contre, ça prend peut-être un tout petit plus de CPU, mais
c'est à mon avis négligeable sur les machines modernes : quelqu'un
voit-il des contre-indications ?
Aucune contre-indication à ma connaissance. Au contraire, les sites en anglais
sur Zend et sur PHP n'en parlent qu'en bien...
Et ce genre de fonctionnalité "avancé" est vraiment d'actualité ainsi que les
systèmes de cache.
Un gros malin de Fi System vient de laisser entendre sur le JDNet que PHP n'est
pas un outil de développement web sérieux !
Laissons-le dire et continuez votre travail formidable sur SPIP.
Cette fonctionnalité est aussi utilisée sur IIS5 avec deux remarques :
- plus de charge cpu sur les serveurs d'appli, mais ça semble ok pour vous
- et un problème plus serieux avec les proxi : si un poste client accepte la
compression, le proxi va charger la page en compressé. Pas de prob pour le
premier donc. Mais si le suivant n'accepte pas la compression, le proxi va
lui envoyer la page compressée qu'il a en cache, alors qu'il ne l'accepte
pas : bug. Une solution, mettre une date de validité sur la page (genre
01/01/2001) qui oblige le proxi à aller rechercher la page. C'est bon sauf
sur les proxi ne respectant pas les normes web : ex noos qui ne respecte pas
ces dates.
Les problématiques pour php me semblent les mêmes.
Cette fonctionnalité est aussi utilisée sur IIS5 avec deux remarques :
- plus de charge cpu sur les serveurs d'appli, mais ça semble ok pour vous
En fait je pars du principe que si un serveur est assez disponible
pour calculer des pages SPIP, il n'a aucun problème à les compresser
ensuite à la volée.... Je ne pense pas que c'est un mauvais calcul,
sauf au cas où le PHP (qui est à la base un langage interprété, enfin
compilé à la volée dans un byte-code non natif) est optimisé à mort
avec des Zend Encoder & co ;))
- et un problème plus serieux avec les proxi : si un poste client accepte la
compression, le proxi va charger la page en compressé. Pas de prob pour le
premier donc. Mais si le suivant n'accepte pas la compression, le proxi va
lui envoyer la page compressée qu'il a en cache, alors qu'il ne l'accepte
pas : bug. Une solution, mettre une date de validité sur la page (genre
01/01/2001) qui oblige le proxi à aller rechercher la page. C'est bon sauf
sur les proxi ne respectant pas les normes web : ex noos qui ne respecte pas
ces dates.
Ca me semblait un peu bidouillesque comme solution, du coup je suis allé
voir la RFC HTTP : ftp://ftp.isi.edu/in-notes/rfc2616.txt
Selon la RFC, c'est le header Vary qui permet de modifier ce comportement.
Ainsi, si le serveur renvoie un Vary: Accept-Encoding, le proxy discriminera
également selon le header client Accept-Encoding et non uniquement selon
l'URL. J'ai vérifié sur un site multilingue avec sélection automatique de la
langue (www.debian.org), et bingo, voici les headers renvoyés par le serveur :
En fait je pars du principe que si un serveur est assez disponible
pour calculer des pages SPIP, il n'a aucun problème à les compresser
ensuite à la volée ...
Je n'ai pas encore regardé le code correspondant, donc j'ai une petite
question : le cache contient maintenant à la fois une version
compressée et une version non compressée, ou on recompresse à chaque
fois que c'est nécessaire ?
Je ne pense pas que c'est un mauvais calcul, sauf au cas où le PHP
(qui est à la base un langage interprété, enfin compilé à la volée
dans un byte-code non natif) est optimisé à mort avec des Zend
Encoder & co ;))
Ouh la la, y'a erreur, là, Zend Encoder n'optimise (en théorie) pas,
il se contente comme son nom l'indique d'encoder le source pour que
son créateur puisse le livrer en "closed source".
Par contre, on peut très facilement vitaminer un serveur PHP avec Zend
Optimiser et Zend Cache.
Zend Optimiser est gratuit et Zend Cache est normalement payant mais
peut être utiliser gratuitement en souscrivant au Zend Cache Co-op
Program. Les seules contraintes sont de placer des logos "Zend Cache
in Action" et "Powered by Zend Cache" sur le site, et de participer
aux études de cas Zend ...
Je n'ai pas encore regardé le code correspondant, donc j'ai une petite
question : le cache contient maintenant à la fois une version
compressée et une version non compressée, ou on recompresse à chaque
fois que c'est nécessaire ?
Non, on est obligé de recompresser à chaque fois (en utilisant
l'output buffering), car le cache peut contenir du code PHP
exécuté à la volée.
Ouh la la, y'a erreur, là, Zend Encoder n'optimise (en théorie) pas,
il se contente comme son nom l'indique d'encoder le source pour que
son créateur puisse le livrer en "closed source".
Par contre, on peut très facilement vitaminer un serveur PHP avec Zend
Optimiser et Zend Cache.
Oui, c'est ce à quoi je faisais allusion, mea culpa.
En fait je pars du principe que si un serveur est assez disponible
pour calculer des pages SPIP, il n'a aucun problème à les compresser
ensuite à la volée.... Je ne pense pas que c'est un mauvais calcul,
Coucou,
as-tu pensé à compresser aussi la partie ecrire/ ?
et là, le programme me propose de downloader le fichier index.php3, mais
ne
l'exécute pas.
Je suppose qu'il s'agit d'une grosse bêtise facile à corriger pour qui
maîtrise ... mais ce n'est pas mon cas.
Merci d'avance pour votre aide.
