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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
