lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: Lucene 3.1 search paralelism per segment doubt
Date Thu, 27 Oct 2011 12:50:12 GMT
On Mon, Oct 10, 2011 at 7:02 AM, Marc Sturlese <> wrote:
> I've read in another thread
> (
> /Since Lucene 2.9, Lucene works on a per segment basis when searching. Since
> Lucene 3.1 it can even parallelize on multiple segments. If you optimize
> your index you only have one segment/
> I'm trying to configure lucene 3.4 to improve my performance as much as
> possible and make the maximum CPU usage. As far as I understood, the optimal
> scenario would be to have as much threads as segments I have in the index.

well are you sure this is optimal?
Using multithreaded search won't actually increase QPS, just make some
queries run faster when the machine is idle.

If its a busy server with lots of requests the optimal scenario might
be to not use it at all, because then its just adding overhead.

> Another question would be, can I achieve the same search performance with an
> index with 5 segments and 5 threads in 3.4 than an optimized index with
> compound file using lucene 2.9? (I know the second env mentioned is much
> worse loading fieldcaches, etc because is not taking advantage of the
> readers per segments)

I would say in general you can without using threads at all.

I think what Uwe was trying to say there is that optimize in general
is probably just wasteful. For a lot of people its just not going to
improve the performance of their search, but it can be very expensive
to do.

My complaint is the naming, i think its the cause of this:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message