: In tests for our implementation (25 concurrent connections generating
: search/sort requests), we've seen performance in terms of requests/second
: drop by a factor of 10, compared to similar tests executing only search
In case it's not clear from Yonik's response: reuse the same
IndexReader/In
On 11/20/05, Jeff Rodenburg <[EMAIL PROTECTED]> wrote:
> Why are numeric fields more onerous in filling the field-cache?
Float.parseFloat() or Integer.parseInt() for each unique term.
-Yonik
Now hiring -- http://forms.cnet.com/slink?231706
Why are numeric fields more onerous in filling the field-cache?
On 11/20/05, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>
> I haven't done measurements, but the first query with a sort on a
> particular field will involve filling the field-cache and that can
> take a while (especially for numeric f
I haven't done measurements, but the first query with a sort on a
particular field will involve filling the field-cache and that can
take a while (especially for numeric fields).
If you haven't already, you should compare the query times of a
"warmed" searcher. Sorted queries will still take long
I've read many comments from users on the list indicating that sorting
may/will be performance-heavy. Is high CPU utilization with a sorted search
one of the expected performance hits?
In tests for our implementation (25 concurrent connections generating
search/sort requests), we've seen performan
