[
https://issues.apache.org/jira/browse/SOLR-17841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108274#comment-18108274
]
Puneet Ahuja commented on SOLR-17841:
-------------------------------------
Ran a text range query, on an index (50M docs dataset) with 12 segments of ~1GB
each, no facetting, caches off, multiThreaded = true, and searchThreads = 0, 2,
4, 8, 12. (0 implies single threaded). Scaling is linear and gets better as we
increase the number of threads to 12, as with 12 threads, each thread has a
segment to work on.
Query used was a 5-clause AND'd text-range query, r{{{}ows=500{}}}, sort by id
!image-2026-08-26-15-39-44-012.png|width=384,height=274!
||searchThreads||mean (ms)||speedup vs ST||
|0|13,692|1.00×|
|2|5,138|2.66×|
|4|2,834|4.83×|
|8|2,429|5.64×|
|12|1,819|7.46×|
> 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: image-2026-08-26-15-39-44-012.png, 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]
