lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <simon.willna...@googlemail.com>
Subject Re: Lucene 3.1 search paralelism per segment doubt
Date Thu, 27 Oct 2011 18:53:51 GMT
On Thu, Oct 27, 2011 at 2:50 PM, Robert Muir <rcmuir@gmail.com> wrote:
> On Mon, Oct 10, 2011 at 7:02 AM, Marc Sturlese <marc.sturlese@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.

I agree with robert, using multiple threads won't make it necessarily
faster. You need to keep in mind that with threads you have
an additional overhead that is not minor. you JVM needs to schedule
threads, switch contexts etc. However when you have like 4 cpus and 8
threads your OS and the JVM will move threads from one cpu to another
including all the instructions and data which might make things even
worse. I don't know what your environment is but in general server
apps you gain concurrency and cpu utilization from incoming requests.
lets say you have 100 concurrent users and 8 segments and 1 thread
each you end up with 800 threads, no good!
>
> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

---------------------------------------------------------------------
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