lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Sturlese <marc.sturl...@gmail.com>
Subject Lucene 3.1 search paralelism per segment doubt
Date Mon, 10 Oct 2011 11:02:35 GMT
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.
The problem here would be that if I rsync the master to the slaves with some
updated documents, these would then have more segments (so there would be
more segments than available threads). 
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)
Can anyone explain me a bit how exactly does it work or point me to some
documentation?



--
View this message in context: http://lucene.472066.n3.nabble.com/Lucene-3-1-search-paralelism-per-segment-doubt-tp3409182p3409182.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message