Bonjour,
des abonnés à Noos me signalent qu'ils n'accèdent plus aux sites spip récents
(http://www.uzine.net ou
http://www.monde-diplomatique.fr/index/pays/algerie ) mais ne sont pas en
mseure de donner assez d'informations...
Une hypothèse est que la compression automatique dans spip ne marche pas
avec le cache de Noos. Est-ce que l'un de vous pourrait faire des essais, en
chargeant et rechargeant les pages avec les outils donnés par noos
(navigateur, proxy, etc.) ?
-- Fil
@ Fil (fil@rezo.net) :
Une hypothèse est que la compression automatique dans spip ne marche pas
avec le cache de Noos. Est-ce que l'un de vous pourrait faire des essais, en
chargeant et rechargeant les pages avec les outils donnés par noos
(navigateur, proxy, etc.) ?
un lien pour tenter d'avancer :
<http://lists.over.net/pipermail/mod_gzip/2001-August/002390.html>
-- Fil
Je n'y arrive pas plus (sous Linux, Konqueror et Mozilla denières versions).
Le message que j'ai est : "Pas de réponse du serveur". Par contre, si ça peut
aider :
lolo:/home/lolo# traceroute www.uzine.net
traceroute to www.uzine.net (193.56.58.62), 30 hops max, 38 byte packets
1 gw.dhcp212-198-165.noos.fr (212.198.165.1) 47.709 ms 8.759 ms 19.687 ms
2 Colomb.cybercable.fr (212.198.1.3) 10.363 ms 8.221 ms 10.375 ms
3 Cartier-pc1-26.noos.net (212.198.1.6) 10.586 ms 9.052 ms 6.761 ms
4 blackburn-ge-030.noos.net (212.198.0.9) 10.850 ms 7.816 ms 8.069 ms
5 alvarado-so-000.noos.net (195.132.16.154) 10.023 ms 19.514 ms 11.141 ms
6 gigabitethernet6-0-0.par-bir-02.carrier1.net (212.4.197.125) 33.872 ms
19.529 ms 25.750 ms
7 pos13-3.pas-bbr-01.carrier1.net (212.4.214.233) 51.621 ms 10.676 ms
19.831 ms
8 serial5-0.paf-ixr-01.carrier1.net (212.4.192.230) 25.782 ms 14.412 ms
24.167 ms
9 grolier-interactive-europe.sfinx.tm.fr (194.68.129.219) 17.250 ms
52.907 ms 25.444 ms
10 S4-1-0.c7k01-v.club-internet.fr (194.117.192.181) 19.272 ms 19.054 ms
39.356 ms
11 194.51.174.14 (194.51.174.14) 387.345 ms 496.554 ms 431.705 ms
12 ns.brainstorm.fr (193.56.58.253) 457.037 ms 382.954 ms 310.839 ms
13 miel.brainstorm.fr (193.56.58.62) 253.371 ms 305.681 ms 639.831 ms
lolo:/home/lolo# traceroute www.monde-diplomatique.fr
traceroute to www.monde-diplomatique.fr (193.56.58.62), 30 hops max, 38 byte
packets
1 gw.dhcp212-198-165.noos.fr (212.198.165.1) 21.339 ms 24.202 ms 19.700
ms
2 Colomb.cybercable.fr (212.198.1.3) 5.164 ms 14.862 ms 11.088 ms
3 Cartier-pc1-26.noos.net (212.198.1.6) 13.118 ms 6.851 ms 11.568 ms
4 blackburn-ge-030.noos.net (212.198.0.9) 6.212 ms 7.904 ms 9.763 ms
5 alvarado-so-000.noos.net (195.132.16.154) 7.817 ms 9.090 ms 7.554 ms
6 gigabitethernet6-0-0.par-bir-02.carrier1.net (212.4.197.125) 18.958 ms
11.066 ms 17.558 ms
7 pos13-3.pas-bbr-01.carrier1.net (212.4.214.233) 118.317 ms 28.318 ms
18.833 ms
8 serial5-0.paf-ixr-01.carrier1.net (212.4.192.230) 20.641 ms 11.622 ms
23.449 ms
9 grolier-interactive-europe.sfinx.tm.fr (194.68.129.219) 16.837 ms
32.351 ms 16.226 ms
10 S4-1-0.c7k01-v.club-internet.fr (194.117.192.181) 21.262 ms 27.417 ms
25.241 ms
11 194.51.174.14 (194.51.174.14) 109.863 ms 98.981 ms 215.494 ms
12 ns.brainstorm.fr (193.56.58.253) 278.539 ms 131.844 ms 161.590 ms
13 miel.brainstorm.fr (193.56.58.62) 261.006 ms 241.087 ms 315.873 ms
lolo:/home/lolo# ping -c 4 www.monde-diplomatique.fr
PING www.monde-diplomatique.fr (193.56.58.62): 56 data bytes
64 bytes from 193.56.58.62: icmp_seq=0 ttl=244 time=464.1 ms
64 bytes from 193.56.58.62: icmp_seq=1 ttl=244 time=579.2 ms
64 bytes from 193.56.58.62: icmp_seq=2 ttl=244 time=324.0 ms
64 bytes from 193.56.58.62: icmp_seq=3 ttl=244 time=458.6 ms
lolo:/home/lolo# ping -c 4 www.uzine.net
PING www.uzine.net (193.56.58.62): 56 data bytes
64 bytes from 193.56.58.62: icmp_seq=0 ttl=244 time=311.6 ms
64 bytes from 193.56.58.62: icmp_seq=1 ttl=244 time=458.1 ms
64 bytes from 193.56.58.62: icmp_seq=2 ttl=244 time=334.8 ms
64 bytes from 193.56.58.62: icmp_seq=3 ttl=244 time=386.0 ms
Salut,
Il m'est venu une id=E9e pour acc=E9l=E9rer certains traitements dans
l'espace priv=E9. Il s'agit de g=E9n=E9rer un fichier tabul=E9 contenant
l'int=E9gralit=E9 de la structure hi=E9rarchique du site. Fabriqu=E9 une
seule fois, et mis =E0 jour uniquement quand on modifie les rubriques
(donc: pas souvent). En effet, toutes les fonctions qui traitent de
la hi=E9rarchie du site font appel =E0 des boucles r=E9cursives, avec
appels mySQL =E0 chaque fois.
Il s'agirait de structurer ce fichier selon le principe:
Classement id_rubrique titre_rubrique
1 5 Premier secteur
1.1 12 Premi=E8re sous-rubrique
1.2 13 Deuxi=E8me sous-rubrique
1.2.1 15 Sous-sous-rubrique
1.3 ....
Un fichier inc_hierarchie.php3 contiendrait toutes les fonctions
permettant de fabriquer ce fichier, de cr=E9er un tableau-m=E9moire avec
les valeurs associ=E9es, et d'exploiter ces informations:
- pour remonter une hi=E9rarchie, il suffit de rechercher les
"classements" en =F4tant des chiffres. Par exemple, partant de la
rubrique class=E9e "1.4.2", son parent est "1.4", puis "1";
- pour afficher les rubriques au m=EAme niveau, facile: ici, toutes les
rubriques commen=E7ant par "1.4"...
- tous les enfants, ce sont les rubriques commen=E7ant par le
classement du parent: ici, "1.4.2...".
Ca permettrait de multiplier les fonctions utilisant la hi=E9rarchie,
sans prendre le risque de multiplier les appels mySQL. Par exemple:
- dans la page "naviguer.php3, l'affichage de la structure du site
=E9viterait des dizaines de requ=EAtes;
- pour afficher une hi=E9rarchie restreinte dans le menu "article plac=E9
dans la rubrique...", il faut pouvoir s'adapter en fonction du nombre
de r=E9sultats; pour que ce soit vraiment optimal, l'id=E9al serait de
pouvoir calculer plusieurs fois le nombre de rubriques obtenues
(profondeur limit=E9e aux secteurs, puis avec une sous-rubrique, puis
deux...);
- =E0 chaque fois qu'on affiche une rubrique (par exemple la hi=E9rarchie
d'un article), je pourrais faire un "survol" (comme la barre de
navigation de l'espace public d'uZine) affichant les rubriques
situ=E9es au m=EAme niveau (mani=E8re d'acc=E9l=E9rer encore la navigation);
- la page "afficher tout le site" =E9viterait des tripot=E9es de requ=EAte=
s...
Qu'est-ce que vous z'en pensez? Je me lance?
ARNO*
Fil a écrit :
Bonjour,
des abonnés à Noos me signalent qu'ils n'accèdent plus aux sites spip récents
(http://www.uzine.net ou
http://www.monde-diplomatique.fr/index/pays/algerie )
suis abonné à noos et confirme…
Bonjour,
Il m'est venu une idée pour accélérer certains traitements dans
l'espace privé. Il s'agit de générer un fichier tabulé contenant
l'intégralité de la structure hiérarchique du site.
[...]
Un fichier inc_hierarchie.php3 contiendrait toutes les fonctions
permettant de fabriquer ce fichier, de créer un tableau-mémoire avec
les valeurs associées, et d'exploiter ces informations
Très très bonne idée !
Mais pourquoi ne pas plus simplement sauvegarder ce "tableau mémoire" dans un
fichier, en le sérialisant ?
Ainsi, on économiserait en plus les temps de transformation depuis un fichier
CSV ...
-Nicolas
Coucou,
Qu'est-ce que vous z'en pensez? Je me lance?
Non ! La 1.2 est presque prête, ce n'est pas le moment de
rajouter un nouveau bousin (par contre il reste un ou deux
trucs dans le TODO).
Sur l'utilité du machin....
- La rapidité de l'espace privé n'est pas cruciale (à moins
de le transformer en chat-room). Donc si ça n'apporte pas
d'amélioration sur l'espace public, je ne suis pas sûr que
ce soit très utile.
- Il faut éviter au maximum les fichiers de données séparées,
vu que tout est censé tenir dans la base. Pour le inc_meta_cache,
j'ai dû faire une exception dont je ne suis pas particulièrement
heureux mais qui est incontournable, vu qu'il s'agit précisément
d'éviter la connexion à la base. Garder à l'esprit que sur un
site type Diplo (le seul type de site où une optimisation des
hiérarchies serait vraiment utile), le parsing et le chargement
du fichier risque d'être prohibitif : les accès rapides à des
données en grande quantité, MySQL est fait pour ça....
- Le naviguer.php3, des dizaines de requêtes ? Il y a une
hiérarchie linéaire en haut (deux ou trois requêtes en général),
l'affichage des sous-rubriques et des sous-sous-rubriques (n + 1
requêtes où n est le nombre de sous-rubriques de l'id_rubrique
en cours, c'est-à-dire en général 4 ou 5). S'il y a vraiment
des dizaines de requêtes (mais je n'y crois pas), c'est que le
machin est mal programmé, donc à reprogrammer ;))
- Dans le "afficher tout", ce qui me paraît le plus gênant, c'est
la taille du fichier et la vitesse d'affichage sous Netscape.
De plus, il faut à chaque rubrique une requête pour savoir si
elle est visible (mode rédacteur) ou supprimable (mode administrateur)
et éventuellement récupérer les articles. Donc pour gagner il
faudrait bidouiller un peu plus le fichier à plat, et donc aussi
le regénérer plus souvent....
Pour l'affichage d'une hiérarchie restreinte, il faut avant tout
en estimer la pertinence par rapport à d'autres solutions (champ
de recherche texte sur le titre de la rubrique, par exemple).
Est-ce que c'est intuitif ? ("où elles sont mes rubriques").
Comment on fait pour sélectionner une rubrique qui n'est pas
dans l'affichage ? On clique sur la racine ? Mais alors après
ça affiche quoi ? Les deux premiers niveaux ? Et il faut cliquer
sur un des premiers niveaux pour de proche en proche atteindre
le niveau de profondeur désiré ? Heuuuuuuuuuuuuuuuuuu......
D'autre part, là aussi c'est pour le Diplo : est-ce que la
machine du Diplo (ou une machine équivalente pour un autre
site équivalent) risque vraiment d'être sur les genoux.
Ca m'étonnerait. Au besoin, calculer ou faire un test 
Suggestion : pour plus de cinquante ou cent rubriques (au choix),
afficher un champ de recherche sur le titre de la rubrique.
Comme il risque d'y avoir des doublons dans les titres, ajouter
un lien "sélectionner directement" qui force l'affichage du
pop-up (intégral, ben oui). Bon, mais j'aimerais qu'on ne s'occupe
de ça qu'après la sortie de la 1.2.
a+
Antoine.
Salut,
Est-ce que l'un des abonnés à Noos ici présents fait tourner PHP
en local ? Ca me permettrait de filer un petit script de test à
exécuter pour essayer de cerner le problème....
Merci
a+
Antoine.
Bonsoir,
le proxy est transparent.
Un proxy n'est jamais "transparent", c'est bien le problème.
Peut-être serait-il possible de conseiller au proxy de ne pas garder
en cache les pages compressées avec les en-têtes HTTP adécquats (dont
je n'ai pas la liste ici), cf http://php.net/header
-Nicolas
Est-ce que l'un des abonnés à Noos ici présents fait tourner PHP
en local ? Ca me permettrait de filer un petit script de test à
exécuter pour essayer de cerner le problème....
Vas-y, balance ... 
-Nicolas
Bonsoir,
Qu'est-ce que vous z'en pensez? Je me lance?
Non ! La 1.2 est presque prête, ce n'est pas le moment de rajouter
un nouveau bousin (par contre il reste un ou deux trucs dans le
TODO).
Tout à fait d'accord, réservons ça pour la 1.3 ...
Je suis en 1.2 beta 13 de ce midi (il faudra revoir ça aussi) sur
http://articles.phpheaven.net/ et je remarque que le traitement
particulier des '<pre>...</pre>' n'est pas effectif alors qu'il
m'avait semblé lire que Fil l'avait fait. Qu'en est-il ?
-Nicolas
This is a multi-part message in MIME format.
--------------9A750DB74D37D7A4761B7F97
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Voilà.
Nicolas Hoizey wrote:
This is a multi-part message in MIME format.
--------------9ACE97ACB0AA0FC2C22824AE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Désolé, plutôt celui-là ;))
--------------9ACE97ACB0AA0FC2C22824AE
Content-Type: application/x-unknown-content-type-PHPCoder.PHPFile;
name="noos.php3"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="noos.php3"
PD8NCg0KCSRodHRwID0gZnNvY2tvcGVuKCJ3d3cudXppbmUubmV0IiwgODApOw0KCWZwdXRz
KCRodHRwLCAiR0VUIC9iYWNrZW5kLnBocDMgSFRUUC8xLjFcbkhvc3Q6IHd3dy51emluZS5u
ZXRcbkFjY2VwdC1FbmNvZGluZzogZ3ppcFxuXG4iKTsNCgl3aGlsZSAoIWZlb2YoJGh0dHAp
KSB7DQoJCSRzID0gZmdldHMoJGh0dHAsIDE2Mzg0KTsNCgkJZWNobyAiJHM8YnI+IjsNCgkJ
Zmx1c2goKTsNCgkJaWYgKCF0cmltKCRzKSkgYnJlYWs7DQoJfQ0KCSRuID0gMDsNCgl3aGls
ZSAoIWZlb2YoJGh0dHApKSB7DQoJCSRuICs9IHN0cmxlbihiaW4yaGV4KGZyZWFkKCRodHRw
LCAxMDI0KSkpLzI7DQoJfQ0KCWVjaG8gIjxwPjxiPlRhaWxsZSBy6WVsbGUgPSAkbjwvYj48
cD4iOw0KCWZjbG9zZSgkaHR0cCk7DQoNCgllY2hvICI8aHI+IjsNCg0KCSRodHRwID0gZnNv
Y2tvcGVuKCJ3d3cudXppbmUubmV0IiwgODApOw0KCWZwdXRzKCRodHRwLCAiR0VUIC9iYWNr
ZW5kLnBocDMgSFRUUC8xLjFcbkhvc3Q6IHd3dy51emluZS5uZXRcblxuIik7DQoJd2hpbGUg
KCFmZW9mKCRodHRwKSkgew0KCQkkcyA9IGZnZXRzKCRodHRwLCAxNjM4NCk7DQoJCWVjaG8g
IiRzPGJyPiI7DQoJCWZsdXNoKCk7DQoJCWlmICghdHJpbSgkcykpIGJyZWFrOw0KCX0NCgkk
biA9IDA7DQoJd2hpbGUgKCFmZW9mKCRodHRwKSkgew0KCQkkbiArPSBzdHJsZW4oYmluMmhl
eChmcmVhZCgkaHR0cCwgMTAyNCkpKS8yOw0KCX0NCgllY2hvICI8cD48Yj5UYWlsbGUgcull
bGxlID0gJG48L2I+PHA+IjsNCglmY2xvc2UoJGh0dHApOw0KDQo/Pg0K
--------------9ACE97ACB0AA0FC2C22824AE--
@ Nicolas Hoizey (nhoizey@phpheaven.net) :
Je suis en 1.2 beta 13 de ce midi (il faudra revoir ça aussi) sur
http://articles.phpheaven.net/ et je remarque que le traitement
particulier des '<pre>...</pre>' n'est pas effectif alors qu'il
m'avait semblé lire que Fil l'avait fait. Qu'en est-il ?
Sur la toute dernière version je tape
<pre align=left>
ligne 1
ligne 2
ligne 3
</pre>
et j'obtiens, à cause de la justif, l'affreux
ligne 1
ligne 2
ligne 3
C'est de ça que tu parles ? C'est sans doute que la fonction |justifier
devrait être un peu modifiée pour ne pas justifier le <pre>...
(Ce que j'avais corrigé c'était simplement pour éviter le double saut de
ligne d'avant :
ligne 1
ligne 2
ligne 3
)
-- Fil
Sur la toute dernière version
Quelque chose a changé à ce niveau depuis ce midi ???
je tape
<pre align=left>
ligne 1
ligne 2
ligne 3
</pre>
et j'obtiens, à cause de la justif, l'affreux
ligne 1
ligne 2
ligne 3
Je n'ai pour ma part aucun problème de justif parce que je fais plutôt
ça :
<html>
<pre>
ligne 1
ligne 2
</pre>
</html>
Comme ça, ça ne me bousille pas le code que je veux afficher, surtout
que c'est du code PHP avec des '.' et ':' qu'il ne faut pas
retoucher ...
Ce que j'avais corrigé c'était simplement pour éviter le double
saut de ligne d'avant
Ca c'est bon, oui.
Je pensais que tu avais aussi bossé sur le respect du code brut, donc
je retire ma remarque.
Par contre, il faudrait aussi préserver les tags HTML, que l'on n'ai
pas à mettre '<br />' au lieu de '<br />' pour pouvoir copier
"brutallement du code" sans avoir à le retoucher ...
-Nicolas
@ Nicolas Hoizey (nhoizey@phpheaven.net) :
> Sur la toute dernière version
Quelque chose a changé à ce niveau depuis ce midi ???
je ne crois pas, non.
Je pensais que tu avais aussi bossé sur le respect du code brut, donc
je retire ma remarque.Par contre, il faudrait aussi préserver les tags HTML, que l'on n'ai
pas à mettre '<br />' au lieu de '<br />' pour pouvoir copier
"brutallement du code" sans avoir à le retoucher ...
Je propose qu'on bosse sur un pseudo-tag de conservation <CODE></CODE> qui
gère à la fois le <pre> et la transformation des < en <
(pour la version 1.3, et il faudra la documenter...)
-- Fil
Je propose qu'on bosse sur un pseudo-tag de conservation
<CODE></CODE> qui gère à la fois le <pre> et la transformation des <
en <
Pourquoi ne pas utiliser '<pre>...</pre>' ???
pour la version 1.3, et il faudra la documenter...
Oui, bien sûr ...
-Nicolas
Salut,
Modif dans la beta 14 (j'esp=E8re que je n'=E9crase rien). Fichiers:
/ecrire/inc_auth.php3
/ecrire/message.php3
Ca d=E9coule de la proposition de Fil (Fil, d=E9sol=E9 de t'impliquer
l=E0-dedans l=E0-dedans ;-)). Seuls sont accessibles en destinataires de
la messagerie interne les r=E9dacteurs qui se sont connect=E9s r=E9cemment.
J'ai choisi 15 jours (Fil proposait 2 mois): en effet, =E7a permet de
limiter aux plus actifs (pour les r=E9dacteurs qui se connectent moins
de deux fois par semaine, de toute fa=E7on, il faut mieux utiliser le
mail...).
Les modifs principales concernent donc "message.php3" (ajout d'un
crit=E8re dans les requ=EAtes mySQL). Dans inc_auth, c'est pour
enregistrer les dates de connexion, m=EAme pour les r=E9dacteurs qui ne
veulent pas appara=EEtre "actuellement en ligne" (puisque cette
fonctionnalit=E9 n'est pas li=E9e =E0 l'"instant messenger" de SPIP).
ARNO*
OK OK. Disons que je r=E9fl=E9chissais =E0 voix haute.
La question que je me poses n'est pas vraiment un probl=E8me
d'optimisation pure et simple (comme tu l'as fait avec Gargantua sur
l'espace public), mais de changement d'=E9chelle. Quoi faire quand un
site d=E9passe une certaine taille? Et j'ai pens=E9 que les requ=EAtes sur
la hi=E9rarchie des rubriques pouvaient poser probl=E8me (sur quoi je te
fais confiance). Je remets donc mon id=E9e dans mon cale=E7on :-))
Amicalement,
ARNO*
Bonjour,
je suis abonné noos et je confirme l'impossibilité récente de charger ces
sites. Par contre, mon site, qui tourne sous 1.0.5 est parfaitement
accessible.
Que veux-tu dire par "les outils fournis par noos" ? Il n'y a pas d'outil
spécifique à ma connaissance et le proxy est transparent.
********************************************
Pierre Mounier
http://www.homo-numericus.net
mailto:contact@homo-numericus.net
*******************************************
----- Original Message -----
From: "Fil" <fil@rezo.net>
To: "spip" <spip@rezo.net>; "spip-dev" <spip-dev@rezo.net>
Sent: lundi 8 octobre 2001 15:50
Subject: [Spip] erreur noos et compression auto
Bonjour,
des abonnés à Noos me signalent qu'ils n'accèdent plus aux sites spip
récents
(http://www.uzine.net ou
http://www.monde-diplomatique.fr/index/pays/algerie ) mais ne sont pas en
mseure de donner assez d'informations...Une hypothèse est que la compression automatique dans spip ne marche pas
avec le cache de Noos. Est-ce que l'un de vous pourrait faire des essais,
en
chargeant et rechargeant les pages avec les outils donnés par noos
(navigateur, proxy, etc.) ?-- Fil
_______________________________________________
spip mailing list
spip@rezo.net
http://listes.rezo.net/mailman/listinfo/spip