lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] Commented: (LUCENE-1997) Explore performance of multi-PQ vs single-PQ sorting API
Date Tue, 03 Nov 2009 00:56:59 GMT


Mark Miller commented on LUCENE-1997:

bq. The point of discussion is memory, unless a few hundred K of memory consumption implies
a "huge perf drop". (I see you are being conservative and using only 1 huge  )

I know, I was purposely avoiding getting into the mem argument and just focusing on how rare
the situation is. And whether there is going to be a huge perf drop with queue sizes of 1000,
I just don't know. The tests have been changing a lot - which is why I think its a little
early to come to final conclusions.

bq. Even with 100 segment which I am guessing you agree that it is rare, it is 400K, (in this
discussion, I am using it as an upper bound, perhaps I should state it more explicitly) and
thus my inability to understand that being a memory concern.

Yes - I do agree its rare.

bq. BTW, I am interested the percentage of "deep paging" you are seeing. You argue it is not
rare, do you have some concrete numbers? The stats I have seen from our production logs and
also web search logs when I was working on that, the percentage is very very very very very
(5 very's) low. (sharp drop usually is at page 4, let alone page 100)

I don't have numbers I can share - but this isn't for situations with users paging through
an interface (like a web search page) - its users that are using Lucene for other tasks -
and there are plenty of those. Lucene is used a lot for websites with users click through
10 results at a time - but its also used in many, many other apps (and I do mean two manys
! :) )

> Explore performance of multi-PQ vs single-PQ sorting API
> --------------------------------------------------------
>                 Key: LUCENE-1997
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.9
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>         Attachments: LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch,
LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch, LUCENE-1997.patch
> Spinoff from recent "lucene 2.9 sorting algorithm" thread on java-dev,
> where a simpler (non-segment-based) comparator API is proposed that
> gathers results into multiple PQs (one per segment) and then merges
> them in the end.
> I started from John's multi-PQ code and worked it into
> contrib/benchmark so that we could run perf tests.  Then I generified
> the Python script I use for running search benchmarks (in
> contrib/benchmark/
> The script first creates indexes with 1M docs (based on
> SortableSingleDocSource, and based on wikipedia, if available).  Then
> it runs various combinations:
>   * Index with 20 balanced segments vs index with the "normal" log
>     segment size
>   * Queries with different numbers of hits (only for wikipedia index)
>   * Different top N
>   * Different sorts (by title, for wikipedia, and by random string,
>     random int, and country for the random index)
> For each test, 7 search rounds are run and the best QPS is kept.  The
> script runs singlePQ then multiPQ, and records the resulting best QPS
> for each and produces table (in Jira format) as output.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message