You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-fr@cocoon.apache.org by Frédéric Glorieux <fr...@ajlsm.com> on 2005/05/04 17:36:21 UTC
Vignettes et cache
Mes remarques concerneront un reader apparemment peu documenté dans Cocoon
<http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
qui permet de redimensionner des images JPG à la volée.
Il est vrai qu'il repose sur des classes spécifiques à SUN, mangeuses de
performances.
J'ai l'impression que l'auteur original est Stefano Mazzocchi, pourtant,
je note qu'il ne l'utilise pas pour son album
<http://gallery.betaversion.org/view_album.php?set_albumName=stefano> (
Powered by Gallery v1.4.3-pl2) alors que son blog est sous cocoon
<http://www.betaversion.org/~stefano/linotype/>.
Est-ce qu'il y aurait des contre-indications à son usage ?
Je vois un premier inconvénient, la cache. Les images générées ont l'air
d'être stockées dans les "store" de cocoon, mais évidemment dans la
limite du nombre d'objets (1000 par défaut). Pour plus d'images,
demandées en de nombreux formats différents, on peut vite dépasser la
limite, surtout qu'elles ne sont pas servies toutes seules.
Sur le modèle de l'action copy-source de Sylvain Wallez, j'ai implémenté
un mécanisme très simple de stockage contrôlé en système de fichier, qui
s'informe au passage si l'image source a été modifiée. Je soumet cette
syntaxe à des gurus de sitemap
<!--
le tuyau qui génère les vignettes, à placer avant celui qui
suit, pour éviter les boucles infinies
-->
<map:match pattern="generate/**_*.*">
<!-- sélecteur selon le fichier source -->
<map:select type="exists">
<map:when test="{global:collection}{1}.jpg">
<map:read type="image" mime-type="image/jpg"
src="{global:collection}{1}.jpg">
<map:parameter name="expires" value="0"/>
<map:parameter name="width" value="{2}"/>
<map:parameter name="height" value="{2}"/>
</map:read>
</map:when>
</map:select>
</map:match>
<!--
le tuyau qui réponds au public
succès de l'action s'il y a un fichier "depend" contre lequel
valider la cache en "dest" (obtenu par appel de "src")
-->
<map:match pattern="**_*.*">
<map:act type="file-store" src="cocoon:/generate/{0}">
<map:parameter name="dest" value="{global:cache}/{0}"/>
<map:parameter name="depend"
value="{global:collection}/{1}.jpg"/>
<!-- on réponds sur la cache -->
<map:read src="{global:cache}/{../0}"/>
</map:act>
<!-- juste pour test, un beau sitemap si la source a
disparu (depend) -->
<map:read src="sitemap.xmap"/>
</map:match>
Le code se résume à quelques lignes que les commiters sauraient bien
mieux faire que moi.
A cette occasion, j'ai considéré les abstractions excalibur (Source).
Pour le cas particulier de ce reader, getLastModified() ou getValidity()
ne répondaient pas grand chose, d'où le besoin d'un bon vieux fichier
dont on est à peu près sûr qu'il répondra une date. C'est la raison du
paramètre "depend", pour comparer au fichier caché, dans l'esprit de la
tâche ant "depend" <http://ant.apache.org/manual/OptionalTasks/depend.html>.
Ceci dit, j'ai pu voir que des tuyaux XML répondait bien un objet
validité. Je suppose que pour le bien, il faudrait le déplier et
chercher des dates quand on peut en obtenir, ou alors, garder en mémoire
des SourceValidity. Mais ce serait refaire une cache, avec une limite à
configurer en nombre d'objets ?
J'ai l'impression qu'une bête comparaison de fichiers, même si cela
demande un accès disque sera globalement plus efficace pour mon problème
initial, générer des vignettes sur des images. En plus, cela me permet
de monter un dossier assez propre pour des exports statiques, ou pour un
mod_cache.
Je ne demande qu'à être corrigé si je faisais erreur.
--
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
Re: Vignettes et cache
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
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
Re: Vignettes et cache
Posted by Sylvain Wallez <sy...@apache.org>.
Frédéric Glorieux wrote:
>
> Sylvain,
>
> merci beaucoup pour ce message
>
>>> <http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
>>
>>
>
> > http://www.grumpykitty.biz/index.html
> > (origine des fonctions de
> > changements de couleur).
>
> très joli
>
>> http://www.ormaz.it/
>> http://cocoongallery.sourceforge.net/
>
>
> C'est intéressant, mais cela ne dépasse pas le millier d'images ?
>
>> La limite de 1000 est la zone tampon en mémoire. Au delà de cette
>> limite, les entrées plus anciennes sont swappées sur disque.
>
>
> S'il s'agit des vignettes, pourquoi pas. Mais prenons le cas d'images
> retaillées (par ex 800px) 200 à 300k, je suis inquiet de les voir
> s'écrire dans un seul fichier de swap, je préfère les avoir quelque
> part. Car au cas où l'on constate des problèmes en exploitation, cela
> permet de faire des coupe-circuit par Apache direct.
Pour répondre au problème du fichier de swap, 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. 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.
>>> Sur le modèle de l'action copy-source de Sylvain Wallez, j'ai
>>> implémenté un mécanisme très simple de stockage contrôlé en système
>>> de fichier, qui s'informe au passage si l'image source a été modifiée.
>>
>
> Si j'ai bien compris, l'action "copy-source" copie un fichier à chaque
> fois qu'elle est executée ?
Oui.
>> J'ai l'impression que laisser le cache Cocoon faire son boulot tout
>> seul comme un grand est la meilleure solution ;-)
>
>
> Refaire une cache est évidemment idiot. Mon alternative était la suivante
>
> * prégénération : ImageMagick, robuste éprouvé, mais mal commode pour
> l'utilisateur final, pareil en dev (en fait la vignette je la voulais
> en 150 plutôt qu'en 96)
> * cocoon à la volée : commode, moins d'install, très bien pour
> prototyper, mais déjà prévoir 256 Mo en -Xmx, incertitude de
> comportement sur les masses
>
> D'où l'envie d'une "prégénération à la volée", ou plus exactement,
> "génération à la demande". Cela pourrait d'ailleurs se transformer en
> une action qui appelle ImageMagick au cas où.
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. 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.
J'ai l'impression que ça ressemble à ce que tu décris.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
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
Re: Vignettes et cache
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
Sylvain,
merci beaucoup pour ce message
>> <http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
> http://www.grumpykitty.biz/index.html
> (origine des fonctions de
> changements de couleur).
très joli
> http://www.ormaz.it/
> http://cocoongallery.sourceforge.net/
C'est intéressant, mais cela ne dépasse pas le millier d'images ?
> La limite de 1000 est la zone tampon en mémoire. Au delà de cette
> limite, les entrées plus anciennes sont swappées sur disque.
S'il s'agit des vignettes, pourquoi pas. Mais prenons le cas d'images
retaillées (par ex 800px) 200 à 300k, je suis inquiet de les voir
s'écrire dans un seul fichier de swap, je préfère les avoir quelque
part. Car au cas où l'on constate des problèmes en exploitation, cela
permet de faire des coupe-circuit par Apache direct.
>> Sur le modèle de l'action copy-source de Sylvain Wallez, j'ai
>> implémenté un mécanisme très simple de stockage contrôlé en système de
>> fichier, qui s'informe au passage si l'image source a été modifiée.
Si j'ai bien compris, l'action "copy-source" copie un fichier à chaque
fois qu'elle est executée ?
>> Je ne demande qu'à être corrigé si je faisais erreur.
> J'ai l'impression que laisser le cache Cocoon faire son boulot tout seul
> comme un grand est la meilleure solution ;-)
Refaire une cache est évidemment idiot. Mon alternative était la suivante
* prégénération : ImageMagick, robuste éprouvé, mais mal commode pour
l'utilisateur final, pareil en dev (en fait la vignette je la voulais en
150 plutôt qu'en 96)
* cocoon à la volée : commode, moins d'install, très bien pour
prototyper, mais déjà prévoir 256 Mo en -Xmx, incertitude de
comportement sur les masses
D'où l'envie d'une "prégénération à la volée", ou plus exactement,
"génération à la demande". Cela pourrait d'ailleurs se transformer en
une action qui appelle ImageMagick au cas où.
--
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
Re: Vignettes et cache
Posted by Sylvain Wallez <sy...@apache.org>.
Frédéric Glorieux wrote:
>
> Mes remarques concerneront un reader apparemment peu documenté dans
> Cocoon
> <http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
>
> qui permet de redimensionner des images JPG à la volée.
>
> Il est vrai qu'il repose sur des classes spécifiques à SUN, mangeuses
> de performances.
>
> J'ai l'impression que l'auteur original est Stefano Mazzocchi,
> pourtant, je note qu'il ne l'utilise pas pour son album
> <http://gallery.betaversion.org/view_album.php?set_albumName=stefano>
> ( Powered by Gallery v1.4.3-pl2) alors que son blog est sous cocoon
> <http://www.betaversion.org/~stefano/linotype/>.
Il l'utilise pour le site de son père : http://www.ormaz.it/
> Est-ce qu'il y aurait des contre-indications à son usage ?
Non. Il est aussi utilisé, entre autres, par CocoonGallery
(http://cocoongallery.sourceforge.net/) et
http://www.grumpykitty.biz/index.html (origine des fonctions de
changements de couleur).
> Je vois un premier inconvénient, la cache. Les images générées ont
> l'air d'être stockées dans les "store" de cocoon, mais évidemment dans
> la limite du nombre d'objets (1000 par défaut). Pour plus d'images,
> demandées en de nombreux formats différents, on peut vite dépasser la
> limite, surtout qu'elles ne sont pas servies toutes seules.
La limite de 1000 est la zone tampon en mémoire. Au delà de cette
limite, les entrées plus anciennes sont swappées sur disque.
> Sur le modèle de l'action copy-source de Sylvain Wallez, j'ai
> implémenté un mécanisme très simple de stockage contrôlé en système de
> fichier, qui s'informe au passage si l'image source a été modifiée.
<snip/>
> Je ne demande qu'à être corrigé si je faisais erreur.
J'ai l'impression que laisser le cache Cocoon faire son boulot tout seul
comme un grand est la meilleure solution ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
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
Re: Vignettes et cache
Posted by Sylvain Wallez <sy...@apache.org>.
Jean-Baptiste Quenot wrote:
>* Sylvain Wallez:
>
>
>
>>Frédéric Glorieux wrote:
>>
>>
>>
>>>Après tests en Cocoon 2.1.5, je ne conseille pas d'utiliser
>>>ImageReader dans un tuyau cachable. Si un OutOfMemory arrive
>>>durant la génération d'une vignette, la vignette corrompue est
>>>mise en cache, et il est bien difficile de s'en débarrasser.
>>>
>>>
>>Hmm... très curieux. Le résultat d'une requête n'est enregistré
>>dans le cache que lorsque sa production est terminée [...] Je
>>n'ai pas fait le test, mais ce que tu décris est théoriquement
>>impossible...
>>
>>
>
>Je confirme qu'en cas de OutOfMemoryError une image de 0 octets
>est renvoyée et gardée en cache. Cela arrive lorsque on essaye
>d'afficher (et donc de calculer) plusieurs dizaines de vignettes
>en même temps. Seul « workaround » pour moi: augmenter la mémoire
>de la JVM.
>
>
Après discussion avec Jean-Baptiste, cette image de 0 octets n'est pas
dans le cache de Cocoon, mais dans celui du navigateur! Faire un "full
refresh" affiche l'image.
Le problème n'est donc pas dû au cache de Cocoon, mais au fait qu'il
renvoie une réponse http que le navigateur considère comme correcte
(200?) au lieu d'un code 500 indiquant une erreur.
Et comme Cocoon ne traite pas les OutOfMemoryError, l'exception remonte
jusqu'au moteur de servlets qui probablement ne fait pas beaucoup mieux...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
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
Re: Vignettes et cache
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Sylvain Wallez:
> Frédéric Glorieux wrote:
>
> > Après tests en Cocoon 2.1.5, je ne conseille pas d'utiliser
> > ImageReader dans un tuyau cachable. Si un OutOfMemory arrive
> > durant la génération d'une vignette, la vignette corrompue est
> > mise en cache, et il est bien difficile de s'en débarrasser.
>
> Hmm... très curieux. Le résultat d'une requête n'est enregistré
> dans le cache que lorsque sa production est terminée [...] Je
> n'ai pas fait le test, mais ce que tu décris est théoriquement
> impossible...
Je confirme qu'en cas de OutOfMemoryError une image de 0 octets
est renvoyée et gardée en cache. Cela arrive lorsque on essaye
d'afficher (et donc de calculer) plusieurs dizaines de vignettes
en même temps. Seul « workaround » pour moi: augmenter la mémoire
de la JVM.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.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
Re: Vignettes et cache
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> Le probl�me est �videmment le peu d'efficacit� de Java2D dans la
> transformation d'images, cocoon n'est pas en cause.
D�sol� pour l'ImageReader (et Java2D), mais outre les performances, il y
a un tr�s gros probl�me de qualit� (mauvais algorythme de
redimensionnement qui exag�re les moirures). Peut-�tre que les images
attach�es passeront sur la liste, compar� � de l'ImageMagick.
Par contre, Merci Cocoon ! J'ai fait une petite action pour invoquer la
CLI ImageMagick (tr�s puissante et tr�s bien document�e) depuis la
sitemap, et avec les InputModule etc, c'est tr�s commode.
--
Fr�d�ric Glorieux ("AJLSM", <http://ajlsm.com>)
Re: Vignettes et cache
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
> Hmm... très curieux. Le résultat d'une requête n'est enregistré dans le
> cache que lorsque sa production est terminée (voir
> o.a.c.components.pipeline.AbstractCachingProcessingPipeline.processReader()).
>
>
> Je n'ai pas fait le test, mais ce que tu décris est théoriquement
> impossible...
Erreur de ma part, c'est en fait un comportement de firefox qui
m'affiche parfois
<< L'image « http://localhost:8888/test/thumbs/lef0012pag043pho047.jpg »
ne peut être affichée, car elle contient des erreurs. >>
En rechargeant 4 à 5 fois, firefox se décide enfin à demander quelque
chose de neuf à cocoon, IE ne pose pas ce problème.
====
Cas test
* Un répertoire d'images, genre sortie brute d'appareil photo à 5M
pixels, commencer à 20 par répertoire, voir quand on passe à la centaine
d'images
* un cocoon démarré sans option de mémoire (sous Windows)
Un bout de sitemap dans un repertoire tranquille
<?xml version="1.0"?>
<!-- test ImageReader pour Sylvain Wallez -->
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:pipelines>
<map:pipeline type="caching">
<map:match pattern="">
<map:generate type="directory" src="images">
<map:parameter name="include" value=".*\.jpg"/>
</map:generate>
<map:transform src="dir2thumbs.xsl"/>
<map:serialize/>
</map:match>
<map:match pattern="thumbs/*.jpg">
<map:read type="image" mime-type="image/jpg"
src="images/{1}.jpg">
<map:parameter name="height" value="100"/>
</map:read>
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
La transformation du directory
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:dir="http://apache.org/cocoon/directory/2.0"
exclude-result-prefixes="dir"
>
<xsl:template match="/">
<html>
<head>
<title>Test ImageReader</title>
</head>
<body>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="*">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="dir:file">
<a href="thumbs/{@name}">
<img src="thumbs/{@name}"/>
</a>
</xsl:template>
</xsl:stylesheet>
===
Dans les logs, une floppée de
11:18:01.896 WARN!! Error for /test/thumbs/lef0012pag004pho005.jpg
java.lang.OutOfMemoryError
11:18:01.996 WARN!! Error for /test/thumbs/lef0012pag005pho006.jpg
java.lang.OutOfMemoryError
11:18:03.909 WARN!! Error for /test/thumbs/lef0012pag011pho015.jpg
java.lang.OutOfMemoryError
11:18:03.989 WARN!! Error for /test/thumbs/lef0012pag012pho016.jpg
java.lang.OutOfMemoryError
11:18:04.880 WARN!! Error for /test/thumbs/lef0012pag015pho019.jpg
java.lang.OutOfMemoryError
Des blancs dans la planche contact.
Le lien sur la vignette unique réponds, mais difficile d'obtenir une
planche pleine dans 64Mo, acceptable dans 256Mo.
Le problème est évidemment le peu d'efficacité de Java2D dans la
transformation d'images, cocoon n'est pas en cause.
--
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
Re: Vignettes et cache
Posted by Sylvain Wallez <sy...@apache.org>.
Frédéric Glorieux wrote:
>
> [Sylvain Wallez]
> > J'ai l'impression que laisser le cache Cocoon faire son boulot tout
> > seul comme un grand est la meilleure solution ;-)
>
> [Frédéric Glorieux]
>
>> J'ai testé l'ImageReader de Cocoon sur 100 nouvelles images à
>> générer. S'il est dans les 64Mo standard java, une image sur 7 à 10
>> passe à la trappe, et cocoon met en cache des fichiers corrompus
>> (d'où ma confiance relative envers la cache cocoon pour ce genre
>> d'opérations).
>
>
> Après tests en Cocoon 2.1.5, je ne conseille pas d'utiliser
> ImageReader dans un tuyau cachable. Si un OutOfMemory arrive durant la
> génération d'une vignette, la vignette corrompue est mise en cache, et
> il est bien difficile de s'en débarrasser.
Hmm... très curieux. Le résultat d'une requête n'est enregistré dans le
cache que lorsque sa production est terminée (voir
o.a.c.components.pipeline.AbstractCachingProcessingPipeline.processReader()).
Je n'ai pas fait le test, mais ce que tu décris est théoriquement
impossible...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
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
Re: Vignettes et cache
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
[Sylvain Wallez]
> J'ai l'impression que laisser le cache Cocoon faire son boulot tout
> seul comme un grand est la meilleure solution ;-)
[Frédéric Glorieux]
> J'ai testé l'ImageReader de Cocoon sur 100 nouvelles images à générer.
> S'il est dans les 64Mo standard java, une image sur 7 à 10 passe à la
> trappe, et cocoon met en cache des fichiers corrompus (d'où ma confiance
> relative envers la cache cocoon pour ce genre d'opérations).
Après tests en Cocoon 2.1.5, je ne conseille pas d'utiliser ImageReader
dans un tuyau cachable. Si un OutOfMemory arrive durant la génération
d'une vignette, la vignette corrompue est mise en cache, et il est bien
difficile de s'en débarrasser. Il est je suppose possible de configurer
son serveur pour diminuer le nombre de requêtes jpg traitable selon la
mémoire que l'on a disposition, ou bien il faudrait organiser des files
d'attente quelque part, ou la petite ligne qui va bien dans la cache
Cocoon...
En attendant, la proposition au début de ce fil de mettre en place sa
propre procédure de cache a au moins cet avantage, on évite d'écrire un
fichier corrompu. Le premier qui demande une grosse page de vignettes
peut avoir quelques blancs, mais le 2e les rebouche, voir le 3e (selon
la mémoire allouée à la JVM). A moitié élégant, mais bon, ça fonctionne,
et les blancs seront probablement d'abord pour les éditeurs, le public
ne les verra pas.
Seul détail, cela ajoute une comparaison entre 2 File.lastModified()
avant que Cocoon serve des fichiers statiques (avec la cache mémoire
pour le coup !).
--
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
Re: Vignettes et cache
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
Salut Pierrick,
> [ma réponse n'est pas une réponse de cocooniste]
Très utile, on ferait vite secte.
> Ce qu'il faut cacher, c'est le timestamp de ton image "grande taille".
>> J'ai l'impression qu'une bête comparaison de dates de fichiers,
>> même si cela
>> demande un accès disque sera globalement plus efficace pour mon
>> problème initial, générer des vignettes sur des images.
> Pas d'accord : trop long. Voir stratégies exposées ci-dessus.
Il y a un truc dont je voudrais être sûr, comment la cache cocoon fait
pour vérifier qu'une ressource n'a pas été modifiée ? Pour le cas
typique d'une source XML transformée par une XSL, quelles que soient les
abstractions, cela revient bien à faire un "lastModified()" sur le
fichier de la source XML et de l'XSL ?
>> <http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
> ... et difficilement portables (il faut un environnement graphique).
> Soit tu charges les JAI (lourd et toujours propriétaire mais néanmoins
> très efficaces), soit tu vas chercher une bibliothèque graphique pur Java.
Mon expérience avec JAI est ancienne, j'en ai gardé le souvenir d'une
API très peu commode. Ceci dit, depuis il y a une tâche Ant qui utilise
<http://ant.apache.org/manual/OptionalTasks/image.html>, il y a
certainement du bon code à imiter
<http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/optional/image/Image.java?view=markup>,
mais bon, JAI n'est toujours pas trivial, voyez cela pour seulement
redimensionner
<http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/types/optional/image/Scale.java?view=markup>.
Et de toute façon cela ne marche qu'en SUN aussi ?
L'apport en performances de JAI me semble décisif pour un GUI ou une
applet, où l'utilisateur reste en JAVA, et veut une réponse rapide. Cela
semble très adapté à des applications de traitements très spécifiques
d'images (voir <http://java.sun.com/products/java-media/jai/success/>),
par contre, pour une appli générique, je ne vois pas que cela puisse
concurrencer photoshop.
Pour les opérations de prégénération, le temps est moins critique, mais
j'avais observé (cela date), que ImageMagick était 2 à 3 fois plus
rapide pour des conversion tiff vers jpg, plus facile à scripter, et
avec beaucoup plus de possibilités. L'inconvénient, c'est un binaire
spécifique à installer par poste. La tâche ant pourrait faire revoir ce
constat, mais cela fait aussi JAI à installer.
En serveur, en génération à la demande, la pression sur la machine est
plus diffuse. Le moment critique est par exemple la page de vignettes.
J'ai testé l'ImageReader de Cocoon sur 100 nouvelles images à générer.
S'il est dans les 64Mo standard java, une image sur 7 à 10 passe à la
trappe, et cocoon met en cache des fichiers corrompus (d'où ma confiance
relative envers la cache cocoon pour ce genre d'opérations).
Avec 256Mo, ça passe, mais je n'ai pas testé avec 100 pages différentes
avec chacune 100 vignettes à générer.
> (pas de problème en cas de serveur statique)
> Comment veux-tu faire autrement ? En service Web, le LRU, c'est encore
> ce qui marche le mieux, non ? En fait l'idéal, c'est un "LRU boosté"
> (dernière consultation * nombre de consultations).
D'où, avoir mes images redimensionnées en fichiers, laisser Apache ou
Cocoon s'optimiser là-dessus.
--
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
Re: Vignettes et cache
Posted by Pierrick Brihaye <pi...@free.fr>.
Salut,
[ma réponse n'est pas une réponse de cocooniste]
Frédéric Glorieux a écrit :
> Mes remarques concerneront un reader apparemment peu documenté dans Cocoon
> <http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/reading/ImageReader.html>
>
> qui permet de redimensionner des images JPG à la volée.
>
> Il est vrai qu'il repose sur des classes spécifiques à SUN, mangeuses de
> performances.
... et difficilement portables (il faut un environnement graphique).
Soit tu charges les JAI (lourd et toujours propriétaire mais néanmoins
très efficaces), soit tu vas chercher une bibliothèque graphique pur Java.
> Je vois un premier inconvénient, la cache. Les images générées ont l'air
> d'être stockées dans les "store" de cocoon, mais évidemment dans la
> limite du nombre d'objets (1000 par défaut). Pour plus d'images,
> demandées en de nombreux formats différents, on peut vite dépasser la
> limite, surtout qu'elles ne sont pas servies toutes seules.
Ce qu'il faut cacher, c'est le timestamp de ton image "grande taille".
Ensuite, 2 solutions (pas de problème en cas de serveur statique) :
1) tu fais du monitoring sur le système de fichiers des images "grande
taille" et tu mets à jour les validités (très pro, mais complexe).
2) tu fais reposer tes validités sur les timestamps des images "grande
taille".
> Sur le modèle de l'action copy-source de Sylvain Wallez, j'ai implémenté
> un mécanisme très simple de stockage contrôlé en système de fichier, qui
> s'informe au passage si l'image source a été modifiée.
Zyva :-)
> Ceci dit, j'ai pu voir que des tuyaux XML répondait bien un objet
> validité. Je suppose que pour le bien, il faudrait le déplier et
> chercher des dates quand on peut en obtenir, ou alors, garder en mémoire
> des SourceValidity. Mais ce serait refaire une cache, avec une limite à
> configurer en nombre d'objets ?
Comment veux-tu faire autrement ? En service Web, le LRU, c'est encore
ce qui marche le mieux, non ? En fait l'idéal, c'est un "LRU boosté"
(dernière consultation * nombre de consultations).
> J'ai l'impression qu'une bête comparaison de fichiers, même si cela
> demande un accès disque sera globalement plus efficace pour mon problème
> initial, générer des vignettes sur des images.
Pas d'accord : trop long. Voir stratégies exposées ci-dessus.
A+
p.b.
---------------------------------------------------------------------
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