[
https://issues.apache.org/jira/browse/SOLR-17841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18086000#comment-18086000
]
Arup Chauhan commented on SOLR-17841:
-------------------------------------
Hey, [~epugh] , [~ichattopadhyaya]
I’d like to take this issue up.
My plan is to first make the performance testing more repeatable, so we can
clearly compare normal search with multithreaded search in a few different
situations.
I’ll start by trying to reproduce the slowdown Renato reported, especially for
range queries. After that, I’ll look into where the extra time is being spent
and whether this is something we can improve, avoid in certain cases, or
document more clearly.
For the first pass, my goal is to produce clear numbers for when multithreaded
search helps, when it hurts, and what kind of follow-up change would make sense.
Does that sound like a useful direction?
> 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
> Fix For: 10.0
>
> Attachments: profile.html
>
>
> 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]
