Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
On Fri, 2008-01-11 at 11:34 +0100, Toke Eskildsen wrote:
> As for shared searcher vs. individual searchers, there was just a
> slight penalty for using individual searchers.

Whoops! Seems like I need better QA for my test-code. I didn't use
individual searchers for each thread when I thought I was. The slight
penalty wrongly observed must have been due to measurement variations.

With the corrected test, some interesting observations about our index
can be made, which will definitely affect our configuration. In the
following, the queries/second is an average over 350.000 queries.
For each query, a search is performed and the content of a specific
field is extracted for the first 20 hits.

== System-summary ==
Dual-core Intel Xeon 5148 2.3 GHz, 8 GB RAM, Linux, Lucene 2.1, 37 GB/10
million documents index, queries taken from production system logs.

== Conventional harddisks (2 * 15000 RPM in software RAID 1) ==
1 thread,  1 searcher:  109 queries/sec
2 threads, 1 searcher:  118 queries/sec
2 threads, 2 searchers: 157 queries/sec
3 threads, 1 searcher:  111 queries/sec
3 threads, 3 searchers: 177 queries/sec
4 threads, 1 searcher:  108 queries/sec
4 threads, 4 searchers: 169 queries/sec

== Solid State Drives (2 * 32 GB Samsung in software RAID 0) ==
1 thread,  1 searcher:  193 queries/sec
2 threads, 1 searcher:  295 queries/sec
2 threads, 2 searchers: 357 queries/sec
3 threads, 1 searcher:  197 queries/sec
3 threads, 3 searchers: 369 queries/sec
4 threads, 1 searcher:  192 queries/sec
4 threads, 4 searchers: 302 queries/sec

Graphs can be viewed at http://wiki.statsbiblioteket.dk/summa/Hardware

For our setup it seems that the usual avoid-multiple-searchers advice is
not valid, neither for conventional harddisks, nor Solid State Drives.
The optimal configuration for our dual-core test machine is three
threads with individual searchers. The obvious question is whether this
can be extended to other cases.

> As for threading, I noticed something strange: On the dual-core
> machine, two threads gave better performance than one, while 4 threads
> gave the same performance as one.

As can be seen above, this strange picture is consistent. 1, 3 and 4
threads with shared searcher performs the same, independent of which
storage the machine uses, while 2 threads performs markedly better.

I've started the same test-suite for Lucene 2.2 and 2.3RC2. It should
be finished in a day or two.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Erick Erickson
There's a section on the Lucene Wiki for real world
experiences etc. After you are satisfied with your
tests, it'd be great if you could add your measurements
to the Wiki!

Best
Erick


On Jan 17, 2008 5:31 AM, Toke Eskildsen <[hidden email]> wrote:

> On Fri, 2008-01-11 at 11:34 +0100, Toke Eskildsen wrote:
> > As for shared searcher vs. individual searchers, there was just a
> > slight penalty for using individual searchers.
>
> Whoops! Seems like I need better QA for my test-code. I didn't use
> individual searchers for each thread when I thought I was. The slight
> penalty wrongly observed must have been due to measurement variations.
>
> With the corrected test, some interesting observations about our index
> can be made, which will definitely affect our configuration. In the
> following, the queries/second is an average over 350.000 queries.
> For each query, a search is performed and the content of a specific
> field is extracted for the first 20 hits.
>
> == System-summary ==
> Dual-core Intel Xeon 5148 2.3 GHz, 8 GB RAM, Linux, Lucene 2.1, 37 GB/10
> million documents index, queries taken from production system logs.
>
> == Conventional harddisks (2 * 15000 RPM in software RAID 1) ==
> 1 thread,  1 searcher:  109 queries/sec
> 2 threads, 1 searcher:  118 queries/sec
> 2 threads, 2 searchers: 157 queries/sec
> 3 threads, 1 searcher:  111 queries/sec
> 3 threads, 3 searchers: 177 queries/sec
> 4 threads, 1 searcher:  108 queries/sec
> 4 threads, 4 searchers: 169 queries/sec
>
> == Solid State Drives (2 * 32 GB Samsung in software RAID 0) ==
> 1 thread,  1 searcher:  193 queries/sec
> 2 threads, 1 searcher:  295 queries/sec
> 2 threads, 2 searchers: 357 queries/sec
> 3 threads, 1 searcher:  197 queries/sec
> 3 threads, 3 searchers: 369 queries/sec
> 4 threads, 1 searcher:  192 queries/sec
> 4 threads, 4 searchers: 302 queries/sec
>
> Graphs can be viewed at http://wiki.statsbiblioteket.dk/summa/Hardware
>
> For our setup it seems that the usual avoid-multiple-searchers advice is
> not valid, neither for conventional harddisks, nor Solid State Drives.
> The optimal configuration for our dual-core test machine is three
> threads with individual searchers. The obvious question is whether this
> can be extended to other cases.
>
> > As for threading, I noticed something strange: On the dual-core
> > machine, two threads gave better performance than one, while 4 threads
> > gave the same performance as one.
>
> As can be seen above, this strange picture is consistent. 1, 3 and 4
> threads with shared searcher performs the same, independent of which
> storage the machine uses, while 2 threads performs markedly better.
>
> I've started the same test-suite for Lucene 2.2 and 2.3RC2. It should
> be finished in a day or two.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Otis Gospodnetic-2
In reply to this post by Toke Eskildsen
This is great and valuable information, Toke(n)!
Just the other day we recommended this multi-IndexSearcher to somebody concerned with low QPS rates their benchmarks revealed.  They were hitting their index with a good number of threads and hitting synchronized blocks in Lucene.  Multiple searchers is one way around that.  Also, your sweet spot of 3 makes sense - keeps all of your cores fully busy.

You are our main SSD info supplier -- keep it coming! :)  And let us know what numbers you get for 2.2 and 2.3, please.

Thanks,
Otis

--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch

----- Original Message ----
From: Toke Eskildsen <[hidden email]>
To: [hidden email]
Sent: Thursday, January 17, 2008 5:31:56 AM
Subject: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

On Fri, 2008-01-11 at 11:34 +0100, Toke Eskildsen wrote:
> As for shared searcher vs. individual searchers, there was just a
> slight penalty for using individual searchers.

Whoops! Seems like I need better QA for my test-code. I didn't use
individual searchers for each thread when I thought I was. The slight
penalty wrongly observed must have been due to measurement variations.

With the corrected test, some interesting observations about our index
can be made, which will definitely affect our configuration. In the
following, the queries/second is an average over 350.000 queries.
For each query, a search is performed and the content of a specific
field is extracted for the first 20 hits.

== System-summary ==
Dual-core Intel Xeon 5148 2.3 GHz, 8 GB RAM, Linux, Lucene 2.1, 37
 GB/10
million documents index, queries taken from production system logs.

== Conventional harddisks (2 * 15000 RPM in software RAID 1) ==
1 thread,  1 searcher:  109 queries/sec
2 threads, 1 searcher:  118 queries/sec
2 threads, 2 searchers: 157 queries/sec
3 threads, 1 searcher:  111 queries/sec
3 threads, 3 searchers: 177 queries/sec
4 threads, 1 searcher:  108 queries/sec
4 threads, 4 searchers: 169 queries/sec

== Solid State Drives (2 * 32 GB Samsung in software RAID 0) ==
1 thread,  1 searcher:  193 queries/sec
2 threads, 1 searcher:  295 queries/sec
2 threads, 2 searchers: 357 queries/sec
3 threads, 1 searcher:  197 queries/sec
3 threads, 3 searchers: 369 queries/sec
4 threads, 1 searcher:  192 queries/sec
4 threads, 4 searchers: 302 queries/sec

Graphs can be viewed at http://wiki.statsbiblioteket.dk/summa/Hardware

For our setup it seems that the usual avoid-multiple-searchers advice
 is
not valid, neither for conventional harddisks, nor Solid State Drives.
The optimal configuration for our dual-core test machine is three
threads with individual searchers. The obvious question is whether this
can be extended to other cases.

> As for threading, I noticed something strange: On the dual-core
> machine, two threads gave better performance than one, while 4
 threads
> gave the same performance as one.

As can be seen above, this strange picture is consistent. 1, 3 and 4
threads with shared searcher performs the same, independent of which
storage the machine uses, while 2 threads performs markedly better.

I've started the same test-suite for Lucene 2.2 and 2.3RC2. It should
be finished in a day or two.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Michael McCandless-2

These results are very interesting.  With 3 threads on SSD your  
searches run 87% faster if you use 3 IndexSearchers instead of  
sharing a single one.

This means, for your test, there are some crazy synchronization  
bottlenecks when searching, which I think we should ferret out and fix.

Have you done any profiling to understand where the threads are  
waiting when you share one IndexSearcher?  EG YourKit can tell you  
where the threads are waiting...

I know there is synchronization used when reading bytes from the  
underlying file descriptor.  We've investigated options to remove  
that (https://issues.apache.org/jira/browse/LUCENE-753) but those  
options seemed to hurt single threaded performance.  I wonder if the  
patch on that issue closes some of this 87% performance loss?

Does anyone know of other synchronization bottlenecks in searching?

Mike

Otis Gospodnetic wrote:

> This is great and valuable information, Toke(n)!
> Just the other day we recommended this multi-IndexSearcher to  
> somebody concerned with low QPS rates their benchmarks revealed.  
> They were hitting their index with a good number of threads and  
> hitting synchronized blocks in Lucene.  Multiple searchers is one  
> way around that.  Also, your sweet spot of 3 makes sense - keeps  
> all of your cores fully busy.
>
> You are our main SSD info supplier -- keep it coming! :)  And let  
> us know what numbers you get for 2.2 and 2.3, please.
>
> Thanks,
> Otis
>
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
> ----- Original Message ----
> From: Toke Eskildsen <[hidden email]>
> To: [hidden email]
> Sent: Thursday, January 17, 2008 5:31:56 AM
> Subject: Multiple searchers (Was: CachingWrapperFilter: why cache  
> per IndexReader?)
>
> On Fri, 2008-01-11 at 11:34 +0100, Toke Eskildsen wrote:
>> As for shared searcher vs. individual searchers, there was just a
>> slight penalty for using individual searchers.
>
> Whoops! Seems like I need better QA for my test-code. I didn't use
> individual searchers for each thread when I thought I was. The slight
> penalty wrongly observed must have been due to measurement variations.
>
> With the corrected test, some interesting observations about our index
> can be made, which will definitely affect our configuration. In the
> following, the queries/second is an average over 350.000 queries.
> For each query, a search is performed and the content of a specific
> field is extracted for the first 20 hits.
>
> == System-summary ==
> Dual-core Intel Xeon 5148 2.3 GHz, 8 GB RAM, Linux, Lucene 2.1, 37
>  GB/10
> million documents index, queries taken from production system logs.
>
> == Conventional harddisks (2 * 15000 RPM in software RAID 1) ==
> 1 thread,  1 searcher:  109 queries/sec
> 2 threads, 1 searcher:  118 queries/sec
> 2 threads, 2 searchers: 157 queries/sec
> 3 threads, 1 searcher:  111 queries/sec
> 3 threads, 3 searchers: 177 queries/sec
> 4 threads, 1 searcher:  108 queries/sec
> 4 threads, 4 searchers: 169 queries/sec
>
> == Solid State Drives (2 * 32 GB Samsung in software RAID 0) ==
> 1 thread,  1 searcher:  193 queries/sec
> 2 threads, 1 searcher:  295 queries/sec
> 2 threads, 2 searchers: 357 queries/sec
> 3 threads, 1 searcher:  197 queries/sec
> 3 threads, 3 searchers: 369 queries/sec
> 4 threads, 1 searcher:  192 queries/sec
> 4 threads, 4 searchers: 302 queries/sec
>
> Graphs can be viewed at http://wiki.statsbiblioteket.dk/summa/Hardware
>
> For our setup it seems that the usual avoid-multiple-searchers advice
>  is
> not valid, neither for conventional harddisks, nor Solid State Drives.
> The optimal configuration for our dual-core test machine is three
> threads with individual searchers. The obvious question is whether  
> this
> can be extended to other cases.
>
>> As for threading, I noticed something strange: On the dual-core
>> machine, two threads gave better performance than one, while 4
>  threads
>> gave the same performance as one.
>
> As can be seen above, this strange picture is consistent. 1, 3 and 4
> threads with shared searcher performs the same, independent of which
> storage the machine uses, while 2 threads performs markedly better.
>
> I've started the same test-suite for Lucene 2.2 and 2.3RC2. It should
> be finished in a day or two.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Mark Miller-3
Anyone tried using this on Lucene yet?
http://www.alphaworks.ibm.com/tech/jla

Michael McCandless wrote:

>
> These results are very interesting.  With 3 threads on SSD your
> searches run 87% faster if you use 3 IndexSearchers instead of sharing
> a single one.
>
> This means, for your test, there are some crazy synchronization
> bottlenecks when searching, which I think we should ferret out and fix.
>
> Have you done any profiling to understand where the threads are
> waiting when you share one IndexSearcher?  EG YourKit can tell you
> where the threads are waiting...
>
> I know there is synchronization used when reading bytes from the
> underlying file descriptor.  We've investigated options to remove that
> (https://issues.apache.org/jira/browse/LUCENE-753) but those options
> seemed to hurt single threaded performance.  I wonder if the patch on
> that issue closes some of this 87% performance loss?
>
> Does anyone know of other synchronization bottlenecks in searching?
>
> Mike
>
> Otis Gospodnetic wrote:
>
>> This is great and valuable information, Toke(n)!
>> Just the other day we recommended this multi-IndexSearcher to
>> somebody concerned with low QPS rates their benchmarks revealed.  
>> They were hitting their index with a good number of threads and
>> hitting synchronized blocks in Lucene.  Multiple searchers is one way
>> around that.  Also, your sweet spot of 3 makes sense - keeps all of
>> your cores fully busy.
>>
>> You are our main SSD info supplier -- keep it coming! :)  And let us
>> know what numbers you get for 2.2 and 2.3, please.
>>
>> Thanks,
>> Otis
>>
>> --
>> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>>
>> ----- Original Message ----
>> From: Toke Eskildsen <[hidden email]>
>> To: [hidden email]
>> Sent: Thursday, January 17, 2008 5:31:56 AM
>> Subject: Multiple searchers (Was: CachingWrapperFilter: why cache per
>> IndexReader?)
>>
>> On Fri, 2008-01-11 at 11:34 +0100, Toke Eskildsen wrote:
>>> As for shared searcher vs. individual searchers, there was just a
>>> slight penalty for using individual searchers.
>>
>> Whoops! Seems like I need better QA for my test-code. I didn't use
>> individual searchers for each thread when I thought I was. The slight
>> penalty wrongly observed must have been due to measurement variations.
>>
>> With the corrected test, some interesting observations about our index
>> can be made, which will definitely affect our configuration. In the
>> following, the queries/second is an average over 350.000 queries.
>> For each query, a search is performed and the content of a specific
>> field is extracted for the first 20 hits.
>>
>> == System-summary ==
>> Dual-core Intel Xeon 5148 2.3 GHz, 8 GB RAM, Linux, Lucene 2.1, 37
>>  GB/10
>> million documents index, queries taken from production system logs.
>>
>> == Conventional harddisks (2 * 15000 RPM in software RAID 1) ==
>> 1 thread,  1 searcher:  109 queries/sec
>> 2 threads, 1 searcher:  118 queries/sec
>> 2 threads, 2 searchers: 157 queries/sec
>> 3 threads, 1 searcher:  111 queries/sec
>> 3 threads, 3 searchers: 177 queries/sec
>> 4 threads, 1 searcher:  108 queries/sec
>> 4 threads, 4 searchers: 169 queries/sec
>>
>> == Solid State Drives (2 * 32 GB Samsung in software RAID 0) ==
>> 1 thread,  1 searcher:  193 queries/sec
>> 2 threads, 1 searcher:  295 queries/sec
>> 2 threads, 2 searchers: 357 queries/sec
>> 3 threads, 1 searcher:  197 queries/sec
>> 3 threads, 3 searchers: 369 queries/sec
>> 4 threads, 1 searcher:  192 queries/sec
>> 4 threads, 4 searchers: 302 queries/sec
>>
>> Graphs can be viewed at http://wiki.statsbiblioteket.dk/summa/Hardware
>>
>> For our setup it seems that the usual avoid-multiple-searchers advice
>>  is
>> not valid, neither for conventional harddisks, nor Solid State Drives.
>> The optimal configuration for our dual-core test machine is three
>> threads with individual searchers. The obvious question is whether this
>> can be extended to other cases.
>>
>>> As for threading, I noticed something strange: On the dual-core
>>> machine, two threads gave better performance than one, while 4
>>  threads
>>> gave the same performance as one.
>>
>> As can be seen above, this strange picture is consistent. 1, 3 and 4
>> threads with shared searcher performs the same, independent of which
>> storage the machine uses, while 2 threads performs markedly better.
>>
>> I've started the same test-suite for Lucene 2.2 and 2.3RC2. It should
>> be finished in a day or two.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
In reply to this post by Michael McCandless-2
On Sun, 2008-01-20 at 05:44 -0500, Michael McCandless wrote:
> These results are very interesting.  With 3 threads on SSD your  
> searches run 87% faster if you use 3 IndexSearchers instead of  
> sharing a single one.

That is my observation, yes. Please note that this is with Lucene 2.1.
I've tried with Lucene 2.3pr2 with the old index though. The relative
results are the same, although overall performance is quite a bit lower.

== Lucene 2.1 - Harddisks (2 * 15000 RPM in software RAID 1) ==
1 thread,  1 searcher:  109 queries/sec
2 threads, 1 searcher:  118 queries/sec
2 threads, 2 searchers: 157 queries/sec
3 threads, 1 searcher:  111 queries/sec
3 threads, 3 searchers: 177 queries/sec
4 threads, 1 searcher:  108 queries/sec
4 threads, 4 searchers: 169 queries/sec

== Lucene 2.1 - SSD (2 * 32 GB Samsung in software RAID 0) ==
1 thread,  1 searcher:  193 queries/sec
2 threads, 1 searcher:  295 queries/sec
2 threads, 2 searchers: 357 queries/sec
3 threads, 1 searcher:  197 queries/sec
3 threads, 3 searchers: 369 queries/sec
4 threads, 1 searcher:  192 queries/sec
4 threads, 4 searchers: 302 queries/sec

== Lucene 2.3pr2 - Harddisks (2 * 15000 RPM in software RAID 1) ==
1 thread,  1 searcher:   93 queries/sec
2 threads, 1 searcher:  112 queries/sec
2 threads, 2 searchers: 135 queries/sec
3 threads, 1 searcher:   96 queries/sec
3 threads, 3 searchers: 153 queries/sec
4 threads, 1 searcher:   98 queries/sec
4 threads, 4 searchers: 150 queries/sec

== Lucene 2.3pr2 - SSD (2 * 32 GB Samsung in software RAID 0) ==
1 thread,  1 searcher:  171 queries/sec
2 threads, 1 searcher:  261 queries/sec
2 threads, 2 searchers: 325 queries/sec
3 threads, 1 searcher:  185 queries/sec
3 threads, 3 searchers: 336 queries/sec
4 threads, 1 searcher:  182 queries/sec
4 threads, 4 searchers: 280 queries/sec

I don't know if the lower performance is because I'm using the old index
instead of generating a new one with Lucene 2.3pr2?

> Have you done any profiling to understand where the threads are  
> waiting when you share one IndexSearcher?

Not at all. The whole threads/searchers-thing in Lucene is quite new to
me - in our production system we use synchronized access to the searcher
with only one search at a time.

>  EG YourKit can tell you where the threads are waiting...

I'll be happy to investigate further. It'll have to wait until friday
though, if it involves more than a trivial amount of time. I'll also put
the (very simple) code online for review. Unfortunately I can't provide
neither the index, nor the queries as I'm not allowed to do so.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Michael McCandless-2

Toke Eskildsen wrote:

> On Sun, 2008-01-20 at 05:44 -0500, Michael McCandless wrote:
>> These results are very interesting.  With 3 threads on SSD your
>> searches run 87% faster if you use 3 IndexSearchers instead of
>> sharing a single one.
>
> That is my observation, yes. Please note that this is with Lucene 2.1.
> I've tried with Lucene 2.3pr2 with the old index though. The relative
> results are the same, although overall performance is quite a bit  
> lower.

Well that is not good news!!  From your results below, it looks like  
2.3 searching is 13.6% slower with hard disks and 8.9% slower with SSD.

We focused heavily on speeding up indexing in 2.3, but did not expect  
searching to slow down.

Please post the code you're using, and any details about the test.  
It seems like your test is a very long running test?

> == Lucene 2.1 - Harddisks (2 * 15000 RPM in software RAID 1) ==
> 1 thread,  1 searcher:  109 queries/sec
> 2 threads, 1 searcher:  118 queries/sec
> 2 threads, 2 searchers: 157 queries/sec
> 3 threads, 1 searcher:  111 queries/sec
> 3 threads, 3 searchers: 177 queries/sec
> 4 threads, 1 searcher:  108 queries/sec
> 4 threads, 4 searchers: 169 queries/sec
>
> == Lucene 2.1 - SSD (2 * 32 GB Samsung in software RAID 0) ==
> 1 thread,  1 searcher:  193 queries/sec
> 2 threads, 1 searcher:  295 queries/sec
> 2 threads, 2 searchers: 357 queries/sec
> 3 threads, 1 searcher:  197 queries/sec
> 3 threads, 3 searchers: 369 queries/sec
> 4 threads, 1 searcher:  192 queries/sec
> 4 threads, 4 searchers: 302 queries/sec
>
> == Lucene 2.3pr2 - Harddisks (2 * 15000 RPM in software RAID 1) ==
> 1 thread,  1 searcher:   93 queries/sec
> 2 threads, 1 searcher:  112 queries/sec
> 2 threads, 2 searchers: 135 queries/sec
> 3 threads, 1 searcher:   96 queries/sec
> 3 threads, 3 searchers: 153 queries/sec
> 4 threads, 1 searcher:   98 queries/sec
> 4 threads, 4 searchers: 150 queries/sec
>
> == Lucene 2.3pr2 - SSD (2 * 32 GB Samsung in software RAID 0) ==
> 1 thread,  1 searcher:  171 queries/sec
> 2 threads, 1 searcher:  261 queries/sec
> 2 threads, 2 searchers: 325 queries/sec
> 3 threads, 1 searcher:  185 queries/sec
> 3 threads, 3 searchers: 336 queries/sec
> 4 threads, 1 searcher:  182 queries/sec
> 4 threads, 4 searchers: 280 queries/sec
>
> I don't know if the lower performance is because I'm using the old  
> index
> instead of generating a new one with Lucene 2.3pr2?

I don't think that should cause the slowdown.  Though this was a good  
test of backwards compatibility on the index format!

>> Have you done any profiling to understand where the threads are
>> waiting when you share one IndexSearcher?
>
> Not at all. The whole threads/searchers-thing in Lucene is quite  
> new to
> me - in our production system we use synchronized access to the  
> searcher
> with only one search at a time.

OK

>>  EG YourKit can tell you where the threads are waiting...
>
> I'll be happy to investigate further. It'll have to wait until friday
> though, if it involves more than a trivial amount of time. I'll  
> also put
> the (very simple) code online for review. Unfortunately I can't  
> provide
> neither the index, nor the queries as I'm not allowed to do so.

OK

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
On Mon, 2008-01-21 at 08:32 -0500, Michael McCandless wrote:
> Well that is not good news!!  From your results below, it looks like  
> 2.3 searching is 13.6% slower with hard disks and 8.9% slower with SSD.

As can be seen, it depends on the configuration. But the overall picture
is very consistent.

> We focused heavily on speeding up indexing in 2.3, but did not expect  
> searching to slow down.
>
> Please post the code you're using, and any details about the test.  
> It seems like your test is a very long running test?

It takes a day or so to go through the combinations for a given Lucene
version, but the machine I use is dedicated to testing our search-
implementation, so it's not a problem to run lengthy tests. If somebody
comes up with a test that can help clarify the issue, I'll be happy to
run it on the hardware.

One could say that the test is fairly unrealistic, as we don't even
begin to approach the 340.000 queries before our index is rotated. If we
only look at the forst 50.000 queries, the difference in speed for
Lucene versions using harddisks is negligible. For SSDs it's quite
visible:

(sorry about the rough dump below, I'm running out of time)

i37 is index size
tx is the number of threads
txu means one searcher/thread

"only" 50.000 queries average response time:

metis_15000_RAID1_8GB_i37_t2_l21.log - 55.9 q/sec
metis_15000_RAID1_8GB_i37_t2_l22.log - 51.8 q/sec
metis_15000_RAID1_8GB_i37_t2_l23.log - 56.3 q/sec
metis_15000_RAID1_8GB_i37_t3_l21.log - 54.7 q/sec
metis_15000_RAID1_8GB_i37_t3_l22.log - 54.1 q/sec
metis_15000_RAID1_8GB_i37_t3_l23.log - 52.9 q/sec
metis_15000_RAID1_8GB_i37_t3u_l21.log - 70.0 q/sec
metis_15000_RAID1_8GB_i37_t3u_l22.log - 70.1 q/sec
metis_15000_RAID1_8GB_i37_t3u_l23.log - 70.3 q/sec

metis_flash_RAID0_8GB_i37_t2_l21.log - 279.6 q/sec
metis_flash_RAID0_8GB_i37_t2_l22.log - 266.1 q/sec
metis_flash_RAID0_8GB_i37_t2_l23.log - 202.3 q/sec
metis_flash_RAID0_8GB_i37_t3_l21.log - 138.9 q/sec
metis_flash_RAID0_8GB_i37_t3_l22.log - 129.6 q/sec
metis_flash_RAID0_8GB_i37_t3_l23.log - 131.9 q/sec
metis_flash_RAID0_8GB_i37_t3u_l21.log - 273.0 q/sec
metis_flash_RAID0_8GB_i37_t3u_l22.log - 254.0 q/sec
metis_flash_RAID0_8GB_i37_t3u_l23.log - 251.8 q/sec

The code I'm using relies on a non-trivial amount of classes in order to
parse the queries, which I can't provide directly due to legal issues.
I've packaged the core files, which can be downloaded at
http://wiki.statsbiblioteket.dk/summa/Hardware?action=AttachFile&do=get&target=SBLucenePerformance0.1.zip

The getSearcher and getNewSearcher methods differ by reusing the
previously created searcher and making a new searcher. The reader for
the searcher uses IndexReader.open(indexPath). I'll see if I can find
the time to make a self-contained test on friday, but no promises.

Toke:
> > I don't know if the lower performance is because I'm using the old  
> > index instead of generating a new one with Lucene 2.3pr2?
>
> I don't think that should cause the slowdown.  Though this was a good  
> test of backwards compatibility on the index format!

The compatibility-part worked great. It was just a matter of changing
the classpath. I'll see if I can steal our production-server for a day
and create a 2.3 index to rule out the possibility that the slowdown is
due to the index-version.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Yonik Seeley-2
On Jan 21, 2008 10:32 AM, Toke Eskildsen <[hidden email]> wrote:
> If we
> only look at the forst 50.000 queries, the difference in speed for
> Lucene versions using harddisks is negligible. For SSDs it's quite
> visible:

Hmmm, I have a hard time thinking what could have slowed down
searching.... perhaps support for multi-level skip lists (w/o those
skip lists actually being present because it's an old index)?

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Michael Busch
Hi Toke,

what kind of queries are you using for your tests? (num query terms,
booleans clauses, phrases, wildcards?)

-Michael


Yonik Seeley wrote:

> On Jan 21, 2008 10:32 AM, Toke Eskildsen <[hidden email]> wrote:
>> If we
>> only look at the forst 50.000 queries, the difference in speed for
>> Lucene versions using harddisks is negligible. For SSDs it's quite
>> visible:
>
> Hmmm, I have a hard time thinking what could have slowed down
> searching.... perhaps support for multi-level skip lists (w/o those
> skip lists actually being present because it's an old index)?
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
On Mon, 2008-01-21 at 11:40 -0800, Michael Busch wrote:
> what kind of queries are you using for your tests? (num query terms,
> booleans clauses, phrases, wildcards?)

No numbers (at least not parsed as numbers), no ranges, some wildcards,
some phrases. The only non-trivial part of the queries is that we use
group expansion so that searches for title:something gets expanded to
(title_type1:something or title_type2:something ...).

The query-parsing takes about 20-40 seconds in total for 470.000
queries. The average number of hits/search is around 5000 with the
classic long tail of a few searches giving millions of hits and a lot of
searches giving hundreds of hits.

Some of the queries are listed below. The majority of queries are simple
with two or three words. Without any qualifiers, the query parser
expands the entered strings to a search in 7 fields.

kreditaftale*
børns relationer  lma_long:"bog" su_dk:"undersøgelser"
detecting information content of corparate announcements using vaiance
increases
Three sisters
author_normalised:"Kittelsen, Theodor"
Cherry garden
kultur fortællinger
Salinger lma_long:"bog" llang:"eng"
hornsleth kristian
templars
templars
borgerskabet
Civillproces
uddannelse
børn død su_dk:"sorg" su_dk:"dødsfald" su_dk:"erindringer"
turen går til
biblioteker integration
plutarch fjender
Danske præster og biskopper om kirkelige vielser af homoseksuelle
pendul* author_normalised:"poe edgar allan"
(china economy ) lma_long:"ebog"
(foucault NOT pendul) lma_long:"tryktbog"



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Michael Busch
Thanks for your detailed answer, Toke! Is your default operator AND or OR?

Toke Eskildsen wrote:

> On Mon, 2008-01-21 at 11:40 -0800, Michael Busch wrote:
>> what kind of queries are you using for your tests? (num query terms,
>> booleans clauses, phrases, wildcards?)
>
> No numbers (at least not parsed as numbers), no ranges, some wildcards,
> some phrases. The only non-trivial part of the queries is that we use
> group expansion so that searches for title:something gets expanded to
> (title_type1:something or title_type2:something ...).
>
> The query-parsing takes about 20-40 seconds in total for 470.000
> queries. The average number of hits/search is around 5000 with the
> classic long tail of a few searches giving millions of hits and a lot of
> searches giving hundreds of hits.
>
> Some of the queries are listed below. The majority of queries are simple
> with two or three words. Without any qualifiers, the query parser
> expands the entered strings to a search in 7 fields.
>
> kreditaftale*
> børns relationer  lma_long:"bog" su_dk:"undersøgelser"
> detecting information content of corparate announcements using vaiance
> increases
> Three sisters
> author_normalised:"Kittelsen, Theodor"
> Cherry garden
> kultur fortællinger
> Salinger lma_long:"bog" llang:"eng"
> hornsleth kristian
> templars
> templars
> borgerskabet
> Civillproces
> uddannelse
> børn død su_dk:"sorg" su_dk:"dødsfald" su_dk:"erindringer"
> turen går til
> biblioteker integration
> plutarch fjender
> Danske præster og biskopper om kirkelige vielser af homoseksuelle
> pendul* author_normalised:"poe edgar allan"
> (china economy ) lma_long:"ebog"
> (foucault NOT pendul) lma_long:"tryktbog"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
On Tue, 2008-01-22 at 02:22 -0800, Michael Busch wrote:
>  Is your default operator AND or OR?

AND


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Michael Busch
OK, then Yonik might be right about the multi-level skiplists code which
is new in 2.2. I'd love to see the performance numbers of the same index
built with 2.3, if possible? You could simply migrate it to 2.3 by using
IndexWriter.addIndexes().

In my performance tests (LUCENE-866) I measured an average performance
gain of 20% for AND queries. Of course, if you run 2.3 against an index
built with 2.1, then the more complex multi-level skiplist code gets
executed on the simpler 2.1 data structures. However, I don't think the
slowdown should be that big (13%). I'll look into the code tomorrow
(have to go to bed now, it's 3am), maybe I can find something out.

Toke Eskildsen wrote:

> On Tue, 2008-01-22 at 02:22 -0800, Michael Busch wrote:
>>  Is your default operator AND or OR?
>
> AND
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
On Tue, 2008-01-22 at 03:08 -0800, Michael Busch wrote:
> OK, then Yonik might be right about the multi-level skiplists code which
> is new in 2.2. I'd love to see the performance numbers of the same index
> built with 2.3, if possible? You could simply migrate it to 2.3 by using
> IndexWriter.addIndexes().

Ah, yes. Just use addIndexes... Silly me.

A quick migrate and new tests paints a whole other picture. I don't have
time for a proper analysis now, but here's some numbers:

(lx is lucene version, v23 is index-version 23, tx is x threads with
shared searcher, txu is x threads with separate searchers)

== Average over the first 50.000 queries ==
metis_15000_RAID1_8GB_i37_t2_l21.log - 55.9 q/sec
metis_15000_RAID1_8GB_i37_t2_l23.log - 56.3 q/sec
metis_15000_RAID1_8GB_i37_v23_t2_l23.log - 57.1 q/sec

metis_15000_RAID1_8GB_i37_t3_l21.log - 54.7 q/sec
metis_15000_RAID1_8GB_i37_t3_l23.log - 52.9 q/sec
metis_15000_RAID1_8GB_i37_v23_t3_l23.log - 54.4 q/sec

metis_15000_RAID1_8GB_i37_t3u_l21.log - 70.0 q/sec
metis_15000_RAID1_8GB_i37_t3u_l23.log - 70.3 q/sec
metis_15000_RAID1_8GB_i37_v23_t3u_l23.log - 70.4 q/sec
---
metis_flash_RAID0_8GB_i37_t2_l21.log - 279.6 q/sec
metis_flash_RAID0_8GB_i37_t2_l23.log - 202.3 q/sec
metis_flash_RAID0_8GB_i37_v23_t2_l23.log - 195.9 q/sec

metis_flash_RAID0_8GB_i37_t3_l21.log - 138.9 q/sec
metis_flash_RAID0_8GB_i37_t3_l23.log - 131.9 q/sec
metis_flash_RAID0_8GB_i37_v23_t3_l23.log - 159.1 q/sec

metis_flash_RAID0_8GB_i37_t3u_l21.log - 273.0 q/sec
metis_flash_RAID0_8GB_i37_t3u_l23.log - 251.8 q/sec
metis_flash_RAID0_8GB_i37_v23_t3u_l23.log - 278.3 q/sec


== Average over the first 340.000 queries ==
metis_15000_RAID1_8GB_i37_t2_l21.log - 109.2 q/sec
metis_15000_RAID1_8GB_i37_t2_l23.log - 111.7 q/sec
metis_15000_RAID1_8GB_i37_v23_t2_l23.log - 118.2 q/sec

metis_15000_RAID1_8GB_i37_t3_l21.log - 103.7 q/sec
metis_15000_RAID1_8GB_i37_t3_l23.log - 95.7 q/sec
metis_15000_RAID1_8GB_i37_v23_t3_l23.log - 108.3 q/sec

metis_15000_RAID1_8GB_i37_t3u_l21.log - 156.8 q/sec
metis_15000_RAID1_8GB_i37_t3u_l23.log - 153.4 q/sec
metis_15000_RAID1_8GB_i37_v23_t3u_l23.log - 188.3 q/sec
---
metis_flash_RAID0_8GB_i37_t2_l21.log - 305.3 q/sec
metis_flash_RAID0_8GB_i37_t2_l23.log - 260.5 q/sec
metis_flash_RAID0_8GB_i37_v23_t2_l23.log - 294.1 q/sec

metis_flash_RAID0_8GB_i37_t3_l21.log - 198.3 q/sec
metis_flash_RAID0_8GB_i37_t3_l23.log - 185.3 q/sec
metis_flash_RAID0_8GB_i37_v23_t3_l23.log - 238.0 q/sec

metis_flash_RAID0_8GB_i37_t3u_l21.log - 378.5 q/sec
metis_flash_RAID0_8GB_i37_t3u_l23.log - 336.1 q/sec
metis_flash_RAID0_8GB_i37_v23_t3u_l23.log - 433.3 q/sec


> In my performance tests (LUCENE-866) I measured an average performance
> gain of 20% for AND queries.

The 20% seems to fit the case with 3 threads and large test, both for
harddisks and SSDs. I'm happy that there was an explanation for the
apparent slowdown for the higher versions and that Lucene 2.3 is
markedly faster than 2.1 on our system.

> Of course, if you run 2.3 against an index built with 2.1, then the more
> complex multi-level skiplist code gets executed on the simpler 2.1 data
> structures. However, I don't think the slowdown should be that big (13%).

If you need me to run tests or generate graphs, just let me know. If
not, I'll stop experimenting with Lucene 2.1 vs. 2.3 and concentrate on
Lucene 2.3: There 's still the matter of how the number of threads and
the number of searchers affects performance. Next step is to tweak the
amount of RAM to get an idea of RAM/index size/speed trade-offs.

(and yes, I'll also try and find the time to put the results on the
Lucene wiki)


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

adb
Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

adb
Toke Eskildsen wrote:
>
> == Average over the first 50.000 queries ==
> metis_flash_RAID0_8GB_i37_t2_l21.log - 279.6 q/sec
> metis_flash_RAID0_8GB_i37_t2_l23.log - 202.3 q/sec
> metis_flash_RAID0_8GB_i37_v23_t2_l23.log - 195.9 q/sec

> == Average over the first 340.000 queries ==
> metis_flash_RAID0_8GB_i37_t2_l21.log - 305.3 q/sec
> metis_flash_RAID0_8GB_i37_t2_l23.log - 260.5 q/sec
> metis_flash_RAID0_8GB_i37_v23_t2_l23.log - 294.1 q/sec

These are odd.  The last case in both of the above shows a slowdown compared to
2.1 index and version and in the first 50K queries, the 2.3 index and version is
even slower than 2.3 with 2.1 index.  It catches up in the longer result set.

Any ideas why that might be.  The shared searcher multiple threads is probably
quite a common use case.

Antony



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
On Thu, 2008-01-24 at 08:18 +1100, Antony Bowesman wrote:
> These are odd.  The last case in both of the above shows a slowdown compared to
> 2.1 index and version and in the first 50K queries, the 2.3 index and version is
> even slower than 2.3 with 2.1 index.  It catches up in the longer result set.
>
> Any ideas why that might be.

Looking at the graphs I can see that the 2 threads / shared searcher is
suspiciously fast at getting up to full speed. It could be because the
disk-read-cache wasn't properly flushed. I'll rerun the test.

I've performed an inspection of graphs for my other published
measurements and they looked as expected. I'll spend some more time on
it tomorrow.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Otis Gospodnetic-2
In reply to this post by Toke Eskildsen
Not me, but it looks useful and something I could actually use (exactly to look at synchronization bottlenecks in situations where many threads are sharing a single IndexSearcher).  Unfortunately, it looks like it works only with IBM's JVM: "Any platform running an IBM®-supplied Java™ SDK or JRE, Version 5.0 or above." :(

Otis

--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch

----- Original Message ----
From: Mark Miller <[hidden email]>
To: [hidden email]
Sent: Sunday, January 20, 2008 9:46:25 AM
Subject: Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Anyone
tried
using
this
on
Lucene
yet?
http://www.alphaworks.ibm.com/tech/jla

Michael
McCandless
wrote:
>
>
These
results
are
very
interesting.  
With
3
threads
on
SSD
your
>
searches
run
87%
faster
if
you
use
3
IndexSearchers
instead
of
sharing
>
a
single
one.
>
>
This
means,
for
your
test,
there
are
some
crazy
synchronization
>
bottlenecks
when
searching,
which
I
think
we
should
ferret
out
and
fix.
>
>
Have
you
done
any
profiling
to
understand
where
the
threads
are
>
waiting
when
you
share
one
IndexSearcher?  
EG
YourKit
can
tell
you
>
where
the
threads
are
waiting...
>
>
I
know
there
is
synchronization
used
when
reading
bytes
from
the
>
underlying
file
descriptor.  
We've
investigated
options
to
remove
that
>
(https://issues.apache.org/jira/browse/LUCENE-753)
but
those
options
>
seemed
to
hurt
single
threaded
performance.  
I
wonder
if
the
patch
on
>
that
issue
closes
some
of
this
87%
performance
loss?
>
>
Does
anyone
know
of
other
synchronization
bottlenecks
in
searching?
>
>
Mike
>
>
Otis
Gospodnetic
wrote:
>
>>
This
is
great
and
valuable
information,
Toke(n)!
>>
Just
the
other
day
we
recommended
this
multi-IndexSearcher
to
>>
somebody
concerned
with
low
QPS
rates
their
benchmarks
revealed.  
>>
They
were
hitting
their
index
with
a
good
number
of
threads
and
>>
hitting
synchronized
blocks
in
Lucene.  
Multiple
searchers
is
one
way
>>
around
that.  
Also,
your
sweet
spot
of
3
makes
sense
-
keeps
all
of
>>
your
cores
fully
busy.
>>
>>
You
are
our
main
SSD
info
supplier
--
keep
it
coming!
:)  
And
let
us
>>
know
what
numbers
you
get
for
2.2
and
2.3,
please.
>>
>>
Thanks,
>>
Otis
>>
>>
--
>>
Sematext
--
http://sematext.com/ 
--
Lucene
-
Solr
-
Nutch
>>
>>
-----
Original
Message
----
>>
From:
Toke
Eskildsen
<[hidden email]>
>>
To:
[hidden email]
>>
Sent:
Thursday,
January
17,
2008
5:31:56
AM
>>
Subject:
Multiple
searchers
(Was:
CachingWrapperFilter:
why
cache
per
>>
IndexReader?)
>>
>>
On
Fri,
2008-01-11
at
11:34
+0100,
Toke
Eskildsen
wrote:
>>>
As
for
shared
searcher
vs.
individual
searchers,
there
was
just
a
>>>
slight
penalty
for
using
individual
searchers.
>>
>>
Whoops!
Seems
like
I
need
better
QA
for
my
test-code.
I
didn't
use
>>
individual
searchers
for
each
thread
when
I
thought
I
was.
The
slight
>>
penalty
wrongly
observed
must
have
been
due
to
measurement
variations.
>>
>>
With
the
corrected
test,
some
interesting
observations
about
our
index
>>
can
be
made,
which
will
definitely
affect
our
configuration.
In
the
>>
following,
the
queries/second
is
an
average
over
350.000
queries.
>>
For
each
query,
a
search
is
performed
and
the
content
of
a
specific
>>
field
is
extracted
for
the
first
20
hits.
>>
>>
==
System-summary
==
>>
Dual-core
Intel
Xeon
5148
2.3
GHz,
8
GB
RAM,
Linux,
Lucene
2.1,
37
>>  
GB/10
>>
million
documents
index,
queries
taken
from
production
system
logs.
>>
>>
==
Conventional
harddisks
(2
*
15000
RPM
in
software
RAID
1)
==
>>
1
thread,  
1
searcher:  
109
queries/sec
>>
2
threads,
1
searcher:  
118
queries/sec
>>
2
threads,
2
searchers:
157
queries/sec
>>
3
threads,
1
searcher:  
111
queries/sec
>>
3
threads,
3
searchers:
177
queries/sec
>>
4
threads,
1
searcher:  
108
queries/sec
>>
4
threads,
4
searchers:
169
queries/sec
>>
>>
==
Solid
State
Drives
(2
*
32
GB
Samsung
in
software
RAID
0)
==
>>
1
thread,  
1
searcher:  
193
queries/sec
>>
2
threads,
1
searcher:  
295
queries/sec
>>
2
threads,
2
searchers:
357
queries/sec
>>
3
threads,
1
searcher:  
197
queries/sec
>>
3
threads,
3
searchers:
369
queries/sec
>>
4
threads,
1
searcher:  
192
queries/sec
>>
4
threads,
4
searchers:
302
queries/sec
>>
>>
Graphs
can
be
viewed
at
http://wiki.statsbiblioteket.dk/summa/Hardware
>>
>>
For
our
setup
it
seems
that
the
usual
avoid-multiple-searchers
advice
>>  
is
>>
not
valid,
neither
for
conventional
harddisks,
nor
Solid
State
Drives.
>>
The
optimal
configuration
for
our
dual-core
test
machine
is
three
>>
threads
with
individual
searchers.
The
obvious
question
is
whether
this
>>
can
be
extended
to
other
cases.
>>
>>>
As
for
threading,
I
noticed
something
strange:
On
the
dual-core
>>>
machine,
two
threads
gave
better
performance
than
one,
while
4
>>  
threads
>>>
gave
the
same
performance
as
one.
>>
>>
As
can
be
seen
above,
this
strange
picture
is
consistent.
1,
3
and
4
>>
threads
with
shared
searcher
performs
the
same,
independent
of
which
>>
storage
the
machine
uses,
while
2
threads
performs
markedly
better.
>>
>>
I've
started
the
same
test-suite
for
Lucene
2.2
and
2.3RC2.
It
should
>>
be
finished
in
a
day
or
two.
>>
>>
>>
---------------------------------------------------------------------
>>
To
unsubscribe,
e-mail:
[hidden email]
>>
For
additional
commands,
e-mail:
[hidden email]
>>
>>
>>
>>
>>
>>
---------------------------------------------------------------------
>>
To
unsubscribe,
e-mail:
[hidden email]
>>
For
additional
commands,
e-mail:
[hidden email]
>>
>
>
>
---------------------------------------------------------------------
>
To
unsubscribe,
e-mail:
[hidden email]
>
For
additional
commands,
e-mail:
[hidden email]
>
>

---------------------------------------------------------------------
To
unsubscribe,
e-mail:
[hidden email]
For
additional
commands,
e-mail:
[hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple searchers (Was: CachingWrapperFilter: why cache per IndexReader?)

Toke Eskildsen
In reply to this post by Erick Erickson
On Thu, 2008-01-17 at 10:24 -0500, Erick Erickson wrote:
> There's a section on the Lucene Wiki for real world
> experiences etc. After you are satisfied with your
> tests, it'd be great if you could add your measurements
> to the Wiki!

Could you please point me to the page? I am unable to find it.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]