Re: [sdx-developers] Gestion de la mémoire

[Pierrick Brihaye]

Re,

>Mes 2 centimes...

Je vais essayer d'aller au-delà :-)

Premièrement, il y a une classe Profiler dans Cocoon. J'ignore la façon dont
elle doit être utilisée car, comme souvent dans ce projet, c'est mal
documenté. Eternelle contradiction entre le désir d'avancer et l'obligation
de consolider...

Maintenant, sur la performance de SDX, voici mon opinion actuelle en l'état
de ma connaissance du code :

L'instanciation et la configuration sont logiquement gourmands en
ressources. On ne pourra rien y changer sauf à revoir le modèle en lançant
par exemple un thread de configuration qui, au fur et à mesure de son
avancée, rendra disponible tel ou tel objet. NetBeans a adopté un processus
de ce genre : à lire les mailing-listes, ça n'est pas sans poser de
problèmes... (quoique le modèle d'instantiation de SDX soit assez
déterministe, contrairement à celui de NetBeans). De plus, je me demande si
ça vaut le coup, un serveur de production pouvant accepter une
initialisation une fois de temps en temps (donc... P5).

Le chargement de documents est extrêmement gourmand. A réserver aux périodes
creuses... On pourrait améliorer en dissociant le processus de chargement,
lent par nature, et celui d'indexation, gourmand en ressources... et indexer
par petits lots les documents chargés mais non encore indexés.

En ce qui concerne l'indexation Lucene, les temps varient de façon
exponentielle (v. échanges récents). J'ai déjà parlé d'autres types de
solutions (et j'en reparlerai ;-). En accès, par contre, c'est très
rapide... je pense même qu'on ne peut quasiment pas faire mieux sauf à
attaquer directement le matériel en assembleur.

En fait, je pense que la performance deSDX est essentiellement liée à celle
de Cocoon et de la JVM. Revoyez en priorité le logging et ensuite le
pooling.

Quelques reflexions en vrac néanmoins :

Les XSP sont compilées : une seule instance en mémoire

Les XSL le sont aussi, mais là, j'ignore comment elles sont mappées en
mémoire...

A ce sujet, je dois dire que j'ai toujours été dubitatif dans le débat DOM
(qui prend de la place en mémoire) / SAX (qui n'en prend pas).

Selon moi, les objets sachant exploiter du SAX ont un footprint mémoire au
moins aussi important qu'un DOM qui, lui, peut se contenter d'objets très
légers. Dans ce combat sans merci, il y a selon moi match nul :-))) J'ai
donc bien peur que nos XSL soient particulièrement gourmandes car, pour
pouvoir attraper convenablement tous les évènements SAX d'une XSL complexe
(celles de sdxworld par exemple :-), il en faut des lignes de bytecode !

XSP, XSL peu importe : l'important pour Cocoon, c'est le concept de
pipelines. Ici, pour moi, c'est clair : le statique ou le pseudo-statique
(requêtes préprogrammées par exemple) doit bénéficier de place dans les
pools, alors qu'associer un gros pool à une requête unique me semble être
contre-productif.

En ce qui concerne SDX lui-même dans un contexte de production (c.a.d.
configuré avec des documents indexés) :

- on pourrait peut-être améliorer le code. Tout objet SDX ou presque se voit
fournir un logger. J'ignore que qu'Avalon prend comme ressources pour ça...
Il y a là un point à étudier.

- la construction d'un objet Results prend du temps. Sous SDX 1 (je n'ai pas
encore testé suffisamment SDX 2), le tri était à la limite du supportable,
mais je crois que Lucene a fait des progrès dans ce domaine... Je pense que
c'est ici qu'on peut envisager quelque chose car ce genre d'objets est
normalement très sollicité dans une appli SDX...

Mais avant de juger SDX à l'aune de sa performance intrinsèque, je pense
qu'il y a pas mal de goulots d'étranglement à supprimer. Tout retour
d'expérience sera bienvenu.

Et un centime de plus...

A bientôt,

p.b.