On Mon, Oct 10, 2011 at 7:02 AM, Marc Sturlese <marc.sturl...@gmail.com> wrote: > I've read in another thread > (http://lucene.472066.n3.nabble.com/Indexing-slower-in-trunk-td3059836.html#a3062991) > /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: https://issues.apache.org/jira/browse/LUCENE-3454 -- lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
