cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Glorieux <frederic.glori...@ajlsm.com>
Subject Re: Vignettes et cache
Date Sat, 07 May 2005 10:05:38 GMT

Pour te donner une idée plus précise de nos types de problèmes,
considérons ce classique <http://gallica.bnf.fr/>. Dans l'idéal,
beaucoup de ressources, très organisées, un traffic raisonable. On
hérite d'une longue tradition de réflexions, de classement ou
d'identification en amont. L'application a une vie beaucoup plus courte
que la donnée, il ne faut pas oublier de la rendre, aussi bien voire
mieux rangée qu'elle a été prêtée.

> La différence entre le cache cocoon sur filesystem et une prégéneration
> est essentiellement le nom des fichiers (un code cryptique dans le cas
> du cache, un nom en rapport avec l'URL dans le cas de la prégénération).

> On est ici dans un cas particulier où le contenu renvoyé ne dépend que
> de l'URL de la requête, et pas d'autres paramètres comme la langue,
> l'état de la session ou autres.

J'ai l'impression que l'URL compatible système de fichiers n'est pas si
rare, du moins pour les tuyaux XML. Un sitemap Cocoon n'est il pas 
souvent à base de chemins droits ?

> Pour répondre au problème du fichier de swap,

Pour un autre jour, rendre sa taille configurable peut être prudent, je
n'ai pas l'impression que cela nuirait à un cocoon défaut de par exemple
fixer à 1Go... Mais passé la limite, cela demande à gérer les sorties.

> on peut utiliser
> l'implémentation filesystem du cache, qui crée un fichier par entrée,
> avec quelques niveaux de répertoires pour éviter un nombre trop
> important de fichiers dans un seul répertoire. C'est l'approche utilisée
> par VNUnet pour un grand nombre de sites de gros volume et à tres fort
> trafic, en combinaison avec mod_cache.

Très générique, mod_cache ou nos navigateurs ne font pas différemment...
Mais il n'y a pas de solution parfaite, cela semble le mieux pour des
gros fichiers, mais pour le coeur de métier de cocoon, petits documents
résultant de nombreuses transformations, le choix d'un gros fichier
semble le bon.

> L'utilisation de reiserfs sur 
> Linux donne d'excellentes performances, mais cette approche est 
> déconseillée sur windows qui n'arrive pas à tenir la cadence.

Je note, mais je ne pense pas que j'en aurais besoin, si les plus gros
binaires sont gérés indépendamment.

> Un utilisateur (désolé, je n'ai pas
> retrouvé le message original) a expliqué une approche intéressante dans 
> cette configuration : une implémentation particulière de pipeline est 
> utilisée, qui écrit sa production sur disque en utilisant l'URL comme 
> chemin de fichier. En frontal de Cocoon, un httpd utilise mod_rewrite : 
> si le fichier demandé existe, il est servi par httpd, autrement on 
> redirige sur Cocoon, et le fichier sera créé. Génération à la demande ! 
> Malgré tout, les documents d'origine sont amenés à changer, et c'est la 
> partie de l'appli qui gère le contenu qui efface les fichiers prégénérés 
> lorsque leur source change.

S'il on a des tuyaux avec plusieurs étapes, et des appels en
protocole cocoon:/ , on risque de copier beaucoup d'états transitoires
un peu partout s'il on ne fait pas attention à son type de pipeline. Et 
s'il on veut plusieurs lieux de stockage, cela prends plusieurs 
"pipeline" à configurer ?

Pour le cas exposé en début de fil, ton action copy-source patchée
suffit, car il n'y a essentiellement qu'une source à vérifier.

Pour plus générique, il me semble qu'en sitemap, une action est plus
lisible, plus configurable. Et si je ne me trompe pas, un 
"ModifiableSource" en destination pourrait très bien être un XML:DB par 
exemple ?

Cela simpliefierait si SitemapSource pouvait répondre à
getLastModified(). Pour l'instant, c'est "return 0;". En déroulant
l'objet Validity (quand il y a des TimeStampValidity), je trouve un
lastModified qui marche pas mal. Cela permet de se passer du paramètre
"depend" proposé au début de ce thread, du moins, quand getValidity()
réponds quelque chose (ce qui n'a pas l'air le cas au bout du reader
d'images).

Je ne sais pas pour d'autres, mais pour moi, c'est beaucoup plus simple 
et facile à contrôler que du Cocoon CLI pour faire de la génération de 
statique.


-- 
Frédéric Glorieux ("AJLSM", <http://ajlsm.com>)





---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message