lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Francois Halleux" <>
Subject RE: ParallelMultiSearcher vs. MultiSearcher
Date Sat, 06 Mar 2004 16:50:29 GMT
Hi Erik,

I would say when the multiple partitions of your indexes are on different
hard-drives and those drives are not under the same RAID-xx set. For
example, when your index is spread over 4 HD under the same (or different)
SCSI controller, I would think that the parallelsearcher would be faster.

Multiple CPUs with multiple hard-drive would help (like 2 CPU/4HD) but is
not a necessity.

In a single/multiple CPU scenario, single HD scenario, I don't see directly
how it could be beneficial, but may be wrong.

I think it should be (much) faster when searching over multiple
RemoteSearchables as well, such as an index spread on multiple machines,
which was the original intent.

Note that it is creating a new thread for each Searchable, so in your case
26, which may be why you see such a slowdown. Using a thread-pool would
surely bring that figure very close to the original 20ms.


Jean-Francois Halleux

-----Original Message-----
From: Erik Hatcher []
Sent: samedi 6 mars 2004 17:20
To: Lucene List
Subject: ParallelMultiSearcher vs. MultiSearcher

Under what conditions would a ParallelMultiSearcher be faster than a
MultiSearcher?  In my brief tests (26 partitioned indexes, all running
local), ParallelMultiSearcher is a factor of 2 or 3 times slower (we're
still talking 20ms versus 60ms though).  I'm searching a partitioned
set of indexes of around 40,000 documents through a RemoteSearchable.

I'm just curious under what circumstances you'd use the new
ParallelMultiSearcher instead of a MultiSearcher?  I saw mention of
multiple hard disk drives being a reason.  Has anyone used it in this
environment and shown that there was a benefit?


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

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

View raw message