[ 
https://issues.apache.org/jira/browse/SOLR-17841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106261#comment-18106261
 ] 

Puneet Ahuja commented on SOLR-17841:
-------------------------------------

I could not reproduce the ~5x slower multithreaded range query on packaged Solr 
11 (after [PR 4724|https://github.com/apache/solr/pull/4724]).
Tested on solr 11.0.0-SNAPSHOT(packaged solr) from a tarball, one local node, 
12-core machine. Index built with solr-bench (TSV (dataset file)→ collection, 
force-merge to 5). Queries were the same range string with 
{{multiThreaded=true/false}}; the node pool was {{solr.searchThreads}} 
(0/2/4/8/12). One client at a time. Facet/queryResult/document caches off.


Mean of 80 timed queries (20 warmup):
||searchThreads||multiThreaded=false||multiThreaded=true||
|0|12.92 s|13.06 s (no pool; MT falls back to ST)|
|2|9.66 s|*3.85 s*|
|4|10.60 s|*3.93 s*|
|8|9.49 s|*3.76 s*|
|12|10.23 s|*3.75 s*|

With a searcher pool, MT is ~3x {*}faster{*}, not slower. Extra threads do not 
help past ~2 (only 5 segments) and do not make MT worse.


> Investigate multithreaded search performance bottlenecks
> --------------------------------------------------------
>
>                 Key: SOLR-17841
>                 URL: https://issues.apache.org/jira/browse/SOLR-17841
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Ishan Chattopadhyaya
>            Priority: Blocker
>              Labels: pull-request-available
>             Fix For: 10.0
>
>         Attachments: profile.html
>
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Ever since multithreaded search (SOLR-13350) was introduced, there has been 
> not much effort to benchmark the performance benefit or investigate the 
> performance bottlenecks. Anecdotally, it is not faster than single threaded 
> execution.
> Thanks to [~kevinliang01] [~liangkaiwen] [~liangkw16] and [~dsmiley] for 
> bringing this up, yesterday on a dense vector working group meeting.
> I'm marking this as a release 10.0 blocker, because it is embarrassing to be 
> releasing with such a gaping hole.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to