jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kiehl <christ...@sulu3000.de>
Subject Re: Search performance : MultiIndex
Date Mon, 29 Oct 2007 09:39:46 GMT
Ard Schrijvers wrote:

> Follow up: it seems that my mergeFactor was way to high (100) resulting
> in many indexes. Setting it to 5 seems to improve trivial searches a
> lot! At the same time, I had maxMergeDocs too small, resulting in many
> indexes as well. 
> Is there any golden rule on how to tune the settings? Would mergeFactor
> 5 and maxMergeDocs 1.000.000 be a proper setting to keep the number of
> indexes small? I suppose a high mergeFactor (100+) would improve writing
> speed but decrease searching performance, isn't?

Those are exactly the settings I use to reduce the number of indexes. I think 
write performance is not an issue because documents are first indexed into an 
in-memory index which is later merged asynchronously into a file system index.

But as you mentioned in your previous mail there are some problematic queries 
which are way to slow like ChildAxisQuery or DescendantSelfAxisQuery. All 
queries that need to read lucene documents instead of just using a query get 
pretty slow with large repositories. But I didn't see a way yet how to 
substantially improve performance while using lucene. I even thought of using 
some other kind of indexing since lucene ...
Internally we use a specific mixin for our documents as a workaround. This way I 
can avoid ChildAxisQueries and the like. I just query for "//element(*, 
foo-mix:document)[...]" for example. But that is just a dirty workaround.

I would really like to find a solution to those problems. Maybe we should use 
some additional kind of index for resolving parent-child relations. Do you have 
any ideas yet how improve performance in those areas?


View raw message