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?
Cheers,
Christoph
