Re: RE : [sdx-users] Performances

[Pierrick Brihaye]

Re,

> > Quant à la quantité de mémoire nécessaire pour recevoir des résultats,
> > elle est marginale... sauf si on met des champs brief. CQFD :-)
>
> Mais on ne peut trier _que_ sur les champs de type brief, donc
> comment faire autrement?

On peut pas :-) Sauf à segmenter ses index en créant autant de bases pour
réduire la charge... Je suis en train de réfléchir à ça ; je vous ferai part
des mes recherches... bientôt ;-)

On peut aussi voir du côté de Lucene (ou d'autres outils capables
d'indexer). Ca fait également de mes recherches :-)

> C'est vrai que je mets aussi les "chapeau" en brief, qui sont un
> résumé de chaque article, pour pouvoir les afficher dans les
> résultats; y a-t-il une autre solution, qui consisterait à inclure
> les chapeaux depuis un autre endroit de stockage, seulement lorsqu'on
> affiche chaque page, au lieu qu'ils soient présents en bloc dans
> l'ensemble du jeu de résultats ?

C'est une option. Vous pouvez aussi utiliser un truc du genre :

1) faire un <xsl:for-each
select="/sdx:document/sdx:results/sdx:result/sdx:address@hidden = 'sdxdocid']">
dans votre XSLT de tranformation finale.
2) utiliser la fonction XSL document sur l'URL
http://localhost:8080/sdx/sdx/api-url/get?app=monapp&base=mabase&monid=valeu
r de l'attribut de l'élément parsé dans le for-each ("@name")
3) récupérer les valeurs que vous voulez afficher

Certes, si vous affichez 20 résultats, vous faites 20 appels, ce qui charge
le serveur, mais, IMHO pas autant que de surcharger les index avec des brief
qui ne seront jamais triés :-)

A voir...

p.b.