If you run a concurrent searches over a million documents, returning only
the matching 500 of each, you will still encounter significant blocking if
there are not many matches between the documents sets - the blocking is even
worse due to the isDeleted() synchronization, as query performance will be
severely impacted the longer each document() call takes.

Using the ThreadLocal demonstrates excellent performance improvements for
multi-threaded queries. Not sure why it should not be used, especially since
it also fixed the synchronization problem between isDeleted() and
document().


-----Original Message-----
From: Yonik Seeley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 17, 2006 1:36 PM
To: java-dev@lucene.apache.org
Subject: Re: FieldsReader synchronized access vs. ThreadLocal ?


On 5/17/06, Robert Engels <[EMAIL PROTECTED]> wrote:
> Since reading a document is a relatively expensive operation

Expensive relative to searching operations that cover 1 million
documents (i.e. you don't want to call doc() a million times)

Solr has a document cache, and I've found that it doesn't help max
throughput that much (I just needed more concurrent searchers to reach
the max), but it does help latency of individual requests.

>[...] Since the
> isDeleted() method uses the same synchronized lock as document(), all
query
> scorers that filter out deleted documents will also be impacted, as they
> will block while the document is being read.

Interesting observation... that lock need not be shared.
Using a different lock would mean aquiring two locks per doc() call,
but it may be worth it to unblock the scorers waiting on isDeleted()

It might also be worth it to make a ReadOnlyIndexReader that didn't
have to deal with issues of synchronizing access to the deleted docs
vector.

If only Sun had done their APIs correctly, we could easily make
non-synchronizing implementations of IndexInput and friends w/o
resorting to ThreadLocals... Ah well.

-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to