[
https://issues.apache.org/jira/browse/LUCENE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060133#comment-17060133
]
Michael Sokolov commented on LUCENE-8929:
-----------------------------------------
> . Having different strategies to sort the leaves and to set the number of
> threads could be dependent on the data and top N size for instance.
Agreed, different strategies win in different situations. In our case,
insertion order is not usually correlated with index sort order, although maybe
we can have some influence there and use the segment-sorting idea +
single-threaded search, however when indexing is in more-or-less random order,
I think this approach gets you better latency at some cost to throughput.
> This makes me wonder where the gains are coming from ?
When it is successful, we collect only the hits we need plus a small buffer
from each segment, and we do them in parallel, so latency is reduced.
Latest patch here has the side effect of cleaning up the branching logic in
IndexSearcher where we choose a strategy, but I realized this is not available
anywhere else we also use these collectors, nor easily to users specializing
IndexSearcher's behavior. If we get enough strategies here we may want to
abstract into a query planner at some point.
Updated perf stats from the patch:
h3. N=10
|| Task|| QPS before|| StdDev|| QPS after||
StdDev|| Pct diff||
| LowTermLastModSort| 2205.95| (7.0%)| 2181.02 |(2.5%)|
-1.1% ( -9% - 8%)|
| HighTermLastModSort| 1167.99| (1.2%)| 1274.97 |(1.2%)|
9.2% ( 6% - 11%)|
| HighTermDayOfYearSort| 1972.26| (0.8%)| 1987.16 |(0.7%)|
0.8% ( 0% - 2%)|
| LowTermDayOfYearSort| 649.64| (0.7%)| 669.05 |(2.5%)|
3.0% ( 0% - 6%)|
h3. N=20
|| Task|| QPS before|| StdDev|| QPS after||
StdDev|| Pct diff||
| LowTermLastModSort| 2239.97| (8.2%)| 2288.43 |(7.8%)|
2.2% ( -12% - 19%)|
| HighTermLastModSort| 1097.37| (1.0%)| 1190.45 |(1.4%)|
8.5% ( 5% - 11%)|
h3. N=100
|| Task|| QPS before|| StdDev|| QPS after||
StdDev|| Pct diff||
| HighTermLastModSort| 847.34| (1.2%)| 978.83 |(1.6%)|
15.5% ( 12% - 18%)|
| LowTermLastModSort| 1540.43| (4.0%)| 1807.39 |(3.9%)|
17.3% ( 9% - 26%)|
| LowTermDayOfYearSort| 621.57| (2.7%)| 656.28 |(1.9%)|
5.6% ( 0% - 10%)|
| HighTermDayOfYearSort| 1497.62| (1.0%)| 1617.08 |(0.9%)|
8.0% ( 6% - 9%)|
h3. N=500
|| Task|| QPS before|| StdDev|| QPS after||
StdDev|| Pct diff||
| HighTermLastModSort| 409.67| (3.7%)| 825.41 |(2.0%)|
101.5% ( 92% - 111%)|
| LowTermLastModSort| 555.95| (7.5%)| 1412.98 |(12.6%)|
154.2% ( 124% - 188%)|
| LowTermDayOfYearSort| 417.82| (3.5%)| 653.06 |(10.9%)|
56.3% ( 40% - 73%)|
| HighTermDayOfYearSort| 498.74| (5.8%)| 1044.63 |(22.4%)|
109.5% ( 76% - 146%) |
Note: in all cases the tests were done with the index sorted according to the
search criterion (these show tests against two different indexes)
> Early Terminating CollectorManager
> ----------------------------------
>
> Key: LUCENE-8929
> URL: https://issues.apache.org/jira/browse/LUCENE-8929
> Project: Lucene - Core
> Issue Type: Sub-task
> Reporter: Atri Sharma
> Priority: Major
> Time Spent: 7.5h
> Remaining Estimate: 0h
>
> We should have an early terminating collector manager which accurately tracks
> hits across all of its collectors and determines when there are enough hits,
> allowing all the collectors to abort.
> The options for the same are:
> 1) Shared total count : Global "scoreboard" where all collectors update their
> current hit count. At the end of each document's collection, collector checks
> if N > threshold, and aborts if true
> 2) State Reporting Collectors: Collectors report their total number of counts
> collected periodically using a callback mechanism, and get a proceed or abort
> decision.
> 1) has the overhead of synchronization in the hot path, 2) can collect
> unnecessary hits before aborting.
> I am planning to work on 2), unless objections
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
