We started doing the same thing (pooling 1 searcher per core) at my work when profiling showed a lot of time hitting synchonized blocks deep inside the SegmentTermReader (? Might be messing the class up) under high load, due to file read()'s using instance variables for seeking. I could dig up the details if you'd like.
-jake On 4/16/08, Karl Wettin <[EMAIL PROTECTED]> wrote: > Toke Eskildsen skrev: > > In the log names, t2 signifies 2 threads with a shared > > searcher, t2u signifies 2 threads with separate searchers. > > > > metis_RAM_24GB_i14_v23_t1_l23.log 530.0 q/sec > > metis_RAM_24GB_i14_v23_t2_l23.log 888.2 q/sec > > Did someone end up investigating this thing with pooled searchers and > why it is a performance boost? > > > karl > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sent from Gmail for mobile | mobile.google.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
