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 Thu, 05 May 2005 09:15:14 GMT

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


Mime
View raw message