I ran a query performance tester against 8-cpu and 16-cpu Xeon servers
(16/32 cpu hyperthreaded). on Linux. Here are the results:
8-cpu: 275 qps
16-cpu: 305 qps
(the dual-core Opteron servers are still faster)
Here is the stack trace of 8 of the 16 query threads during the test:
at org.apache.lucene.index.SegmentReader.document(SegmentReader.java
:281)
- waiting to lock <0x0000002adf5b2110> (a
org.apache.lucene.index.SegmentReader)
at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:83)
at org.apache.lucene.search.MultiSearcher.doc(MultiSearcher.java
:146)
at org.apache.lucene.search.Hits.doc(Hits.java:103)
SegmentReader.document is a synchronized method. I have one stored field
(binary, uncompressed) with and average length of 0.5Kb. The retrieval of
this stored field is within this synchronized code. Since I am using
MMapDirectory, does this retrieval need to be synchronized?
Peter
On 2/23/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
>
> Yonik,
>
> We're investigating both approaches.
> Yes, the resources (and permutations) are dizzying!
>
> Peter
>
>
> On 2/23/06, Yonik Seeley < [EMAIL PROTECTED]> wrote:
> >
> > Wow, some resources!
> > Would it be cheaper / more scalable to copy the index to multiple
> > boxes and loadbalance requests across them?
> >
> > -Yonik
> >
> > On 2/23/06, Peter Keegan <[EMAIL PROTECTED]> wrote:
> > > Since I seem to be cpu-bound right now, I'll be trying a 16-cpu system
> > next
> > > (32 with hyperthreading), on LinTel. I may give JRockit another go
> > around
> > > then.
> > >
> > > Thanks,
> > > Peter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
