[
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 3:50 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 and x86
handle that stuff a bit differently under the hood.
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 and x86
handle that stuff a bit differently under the hood.
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?
> 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]
