sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sdx-users] Upload Mystery


From: Pierrick Brihaye
Subject: Re: [sdx-users] Upload Mystery
Date: Fri, 7 Feb 2003 23:18:33 +0100

Re,

> > Un <sdx:uploadDocument> avec un attribut url génère par défaut un
> > *HTMLDocument* (je l'ai déjà signalé) ; il vaut donc mieux forcer
> > le type (attribut "type") du document à "text/xml". Je n'ai pas
> > encore regardé, mais ça devrait éviter un transtypage assez
> > dispendieux en ressources.
>
> Un attribut du document xml?

Nuance... un attribut relatif au document *indexable* : ça peut être un type
MIME "text/xml" ou "text/html".

> dans la déclaration xml?

Non, dans l'élément <sdx:uploadDocument>

> De toutes façons ça a lieu aussi pour chaque doc d'un dir, donc
> ça n'explique pas l'écart de délai?

Non, pour 2 raisons :

1) quand on utilise un dir, on est par défaut en "text/xml" (et non pas en
"text/html" comme dans le cas d'un file), mais ce n'est pas grand chose par
rapport au point suivant...
2) quand on charge un dir, on appelle la méthode index qui prend ce fameux
tableau de documents, et là, l'index n'est optimisé que tous les X documents
(25 par défaut).

Mais bon une optimisation tous les 25 documents quand on en a 200.000... ce
n'est pas terrible. De plus, votre calcul est faux, hélas : vous avez
postulé que le temps d'indexation était arithmétique. Grave erreur !
http://www.nongnu.org/sdx/docs/html/doc-sdx2/fr/charge/mesures/ajlsm-200301/
indexation.html
On est plutôt en géométrique même si ça c'est considérablement amélioré du
côté de chez Lucene.

En fait, il faudrait absolument que ce setBatchMax soit personnalisable
(essentiellement en fonction de la mémoire disponible) pour pouvoir ajuster
la performance.

> Si, c'est certainement le pb! (du coup pas besoin d'utiliser file...)

C'est *sans aucun doute* ça :-)

> Ce qui serait idéal ça serait de pouvoir envoyer un paramètre du genre
> &optimize=no

Mmmmh. Dans ce cas, c'est Lucene qui effondrerait votre système de fichiers
(j'ai testé avec SDX-1 ;-).

> (avec un défaut à yes) mais bon en attendant comment faire?

Voilà :

La méthode qui fixe le seuil d'optimisation est
IndexParameters.setBatchMax(xxx)
L'idée serait d'attraper l'objet IndexParameters utilisé par l'upload et de
lui appliquer cette méthode... avec la valeur désirée...

On y va :

Je vous recommande de remplacer le <sdx:uploadDocuments> de votre xsp par le
*contenu* du template de cet élément (issu de la logicsheet
sdx_actions.xsl). Pas la peine de faire dans la finesse... vous devez
pouvoir recopier ça tel quel. Pour vérifier, faite un upload après le
copier/coller.

Si ça tourne, on continue...

Dans ce code, juste après :
<xsl:call-template name="sdx:index"/> (qui instancie un objet
IndexParameter), insérez :
sdx_index.setBatchMax(xxx).

Bien sûr, vous pouvez fignoler pour passer un paramètre à setBatchMax
(request.getParameter("mon_para_perso")) et ne réduire le code qu'à la
portion nécessaire.

Je reconnais cependant qu'il devrait être facile de gérer ça via la
logicsheet (via un paramètre ad hoc) ou directement dans la config...

> > Sinon, on peut toujours utiliser dir (sachant qu'on ne possède, hélas,
> > pas de "urldir" !)
>
> C'est là qu'est l'os...

Je ne vous le fais pas dire :-)

> Ca me semble très intéressant comme piste, mais je ne comprends pas
> concrètement comment "constuire un tableau en xsp"? Pouvez vous m'en
> dire plus?

<xsp:logic>
/* voir comment construire un tableau java */
</xsp:logic>

Plus sérieusement, lisez le code source des logicsheet (avec de l'aspirine).
Ces fichiers sont en fait de gigantesques XSP. Mais, soit dit en passant,
les parties relatives aux uploads ne sont pas les parties les plus
difficiles !

... pas comme celle des requêtes sur les intervalles de dates par exemple
:-)

A bientôt,

p.b.











reply via email to

[Prev in Thread] Current Thread [Next in Thread]