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 21:28:59 +0100

Re,

>Ceci dit, je le
>répète, le goulot d'étranglement est peut-être tout simplement dans la
>logicsheet. Je vais regarder...

Résultat des courses après un premier coup d'oeil :

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.

Sinon, la méthode GetLength() des documents fournis par une URL et qui,
comme son nom l'indique donne la longueur du document, n'est pas d'un
rendement extraordinaire. Mais, à part sur un JDBCRepository, elle n'est pas
utilisée.

Sinon, le *gros* truc qui semble vous freiner sur une URL (et ce serait
pareil pour un file), c'est le :
this.luceneSearchIndex.optimize();

... dans LuceneDocumentBase, à la fin de :
public synchronized void index(IndexableDocument doc, Repository repository,
IndexParameters params, ContentHandler handler).

En clair, ça veut dire qu'on prend toutes les ressources de l'appli
(synchronized) pour optimiser (optmize) l'index quand on a indexé *un*
document (doc). Quand on en a 200.000, brrrrr...

Il y a d'ailleurs un commentaire du programmeur là-dessus :

/*TODOPerformance: is it really necessary to optimize after every addition
to the index, i think so based upon little testing
*this may be problematic for large document bases?rbp*/

N'est-ce pas là votre problème ?

A vrai dire, je pense comme Rasik : si on indexe *un* document, je trouve
normal qu'on fasse une optimisation après.

Sinon, on peut toujours utiliser dir (sachant qu'on ne possède, hélas, pas
de "urldir" !)... ou  la méthode :

public synchronized void index(IndexableDocument[] docs, Repository
repository, IndexParameters params, ContentHandler handler)

qui, elle, prend un *tableau* de documents et qui a une politique
d'optimisation... plus modérée.

Donc :

- soit vous bâtissez votre tableau de documents en XSP selon votre logique
applicative (les 100 premiers documents, les 100 plus vieux documents, les
100 plsu gros... tout ce que vous voudrez !)
- soit vous utilisez un dir... malheureusement local :-(

Pour finir... je compatis :-)

A+

p.b.











reply via email to

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