[
https://issues.apache.org/jira/browse/SOLR-17841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110353#comment-18110353
]
Arup Chauhan edited comment on SOLR-17841 at 9/1/26 4:16 PM:
-------------------------------------------------------------
[~dsmiley]
That makes sense, thanks. Agreed that JMH itself being pure Java makes it chip
agnostic.
My concern though is less about JMH and more about the results we get from it.
This issue is specifically about how search behaves under multiple threads, and
that kind of thing can genuinely be affected by chip differences like cache
size and how cores are scheduled.
Apple Silicon or Arm and x86 handle that stuff a bit differently under the hood.
Unless it is a bit too much specific or chore, I can run the same benchmark
with same variables, on Apple Silicon if needed, that can give us an additional
data point.
What do you think?
was (Author: JIRAUSER312424):
[~dsmiley]
That makes sense, thanks. Agreed that JMH itself being pure Java makes it chip
agnostic.
My concern though is less about JMH and more about the results we get from it.
This issue is specifically about how search behaves under multiple threads, and
that kind of thing can genuinely be affected by chip differences like cache
size and how cores are scheduled.
Apple Silicon or Arm and x86 handle that stuff a bit differently under the hood.
Unless it is a bit too much specific or chore, I can run the same benchmark
with same variables, on Apple Silicon if needed, that can give us an additional
data point.
What do you think?
With more data points we will have a better context if we decide to go dig
deeper into
[SOLR-17673|https://issues.apache.org/jira/browse/SOLR-17673]
> 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]
