-
Notifications
You must be signed in to change notification settings - Fork 681
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SOLR-13350, SOLR-17298: use multiThreaded=false default; document multiThreaded parameter; #2596
SOLR-13350, SOLR-17298: use multiThreaded=false default; document multiThreaded parameter; #2596
Conversation
…; add responseHeader.multiThreadedUsed element;
https://github.com/apache/solr/actions/runs/10110021801/job/27959091476?pr=2596 CI failure looks unrelated
|
I'm not sure about the conversion to Boolean and only reporting if it was requested. That will still leave the default decision unclear if it wasn't requested explicitly. I think the logging of the query should be sufficient to identify if it was requested, and the logging in the code should report what was ultimately decided regardless of the request. |
Co-authored-by: Gus Heck <[email protected]>
if (log.isDebugEnabled()) { | ||
log.debug("skipping collector manager"); | ||
if (cmd.getMultiThreaded() != null) { | ||
// report multi-threading (non-)use only if multi-threading was explicitly (not) requested | ||
log.info("SINGLE THREADED search, skipping collector manager"); | ||
} else { | ||
log.debug("SINGLE THREADED search, skipping collector manager"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks @cpoerschke. +1 to merge. |
solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java
Outdated
Show resolved
Hide resolved
If unset or set to `false`, then the multi-threaded search implementation will not be used for the query. | ||
If set to `true`, then use the multi-threaded search implementation if it is supported for the query. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested simple wording:
'true' or 'false' controls if Solr may use more than one thread to satisfy the request.
It presently is only considered forQueryComponent
to search across Lucene's segments in parallel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could see us using this parameter in the future for indexing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested simple wording:
'true' or 'false' controls if Solr may use more than one thread to satisfy the request.
It presently is only considered forQueryComponent
to search across Lucene's segments in parallel.
Thanks! Will revise. I'd also intended to cross-reference the configuring-solr-xml.adoc
documentation for indexSearcherExecutorThreads
but lost track of that due to .adoc syntax.
…adoc#indexSearcherExecutorThreads
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, some word-smithing suggestions for the docs and probably we should refer to this as experimental.
@@ -371,7 +371,7 @@ public void process(ResponseBuilder rb) throws IOException { | |||
return; | |||
} | |||
|
|||
final boolean multiThreaded = params.getBool("multiThreaded", true); | |||
final boolean multiThreaded = params.getBool(CommonParams.MULTI_THREADED, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
@@ -103,7 +103,7 @@ Other Changes | |||
================== 9.7.0 ================== | |||
New Features | |||
--------------------- | |||
* SOLR-13350: Multithreaded search execution (Ishan Chattopadhyaya, Mark Miller, Christine Poerschke, David Smiley, noble) | |||
* SOLR-13350, SOLR-17298: Opt-in multithreaded search execution (Ishan Chattopadhyaya, Mark Miller, Christine Poerschke, David Smiley, noble, Gus Heck) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe call it experimental too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be in Optimizations? There is no new capability here; it's about performance. I realize a lot of work went into this but a user doesn't care; it's just a performance thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine to leave it in as a feature for 2 reasons: 1) It's actively enabled/disabled by the user, and 2) This might affect how one thinks about sizing and sharding strategies. Previously on a cluster with a small to moderate sized index that isn't changing size quickly one might have added shards to be sure to take advantage of many cpu cores. Though I'm not sure if we expose it, one could now think of going single shard, multi-thread and limiting the segment size to ensure there are enough segments to fill up your cpu-cores... One could even think of trying a merge policy that targets maintaining a specific number of segments so that every search is fully utilizing the cores available (or utilizing a target fraction) on boxes with many cores?
It's a performance thing, but it's not an invisible touch free performance thing, which is what I think of when I use the word optimization.
|=== | ||
|
||
This parameter set to `true` or `false` controls if Solr may use more than one thread to satisfy the request. | ||
It presently is only considered for QueryComponent to search across Lucene's segments in parallel and the xref:configuration-guide:configuring-solr-xml.adoc#indexSearcherExecutorThreads[indexSearcherExecutorThreads] value can be customised in the `solr.xml` file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"It presently is only considered for" is unclear/confusing. Perhaps "Specifically this enables"
Also:
"segments in parallel and the xref:..." should either have a comma after parallel or be broken into two sentences (I prefer 2 sentences)
Also do we have a standardized way to mark things experimental in the docs (if not just mention it?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was even more unclear before :-). The "it presently" portion conveys it may have expanded uses later. After all, we chose a super generic name here instead of something referencing segment parallelism.
Indeed, it'd be nice to have a standard way, maybe an icon, to label experimental stuff. Ah well, even just textually [EXPERIMENTAL]
@@ -103,7 +103,7 @@ Other Changes | |||
================== 9.7.0 ================== | |||
New Features | |||
--------------------- | |||
* SOLR-13350: Multithreaded search execution (Ishan Chattopadhyaya, Mark Miller, Christine Poerschke, David Smiley, noble) | |||
* SOLR-13350, SOLR-17298: Opt-in multithreaded search execution (Ishan Chattopadhyaya, Mark Miller, Christine Poerschke, David Smiley, noble, Gus Heck) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@markrmiller I didn't know that you contributed to this effort; what did you do?
Thanks everyone for your inputs here so far! Unfortunately I won't have bandwidth to iterate on this today or so. "Allow edits and access to secrets by maintainers" is enabled on the PR i.e. everyone please feel free to make edits and/or merge as you see fit. Thank you. cc/FYI @anshumg as 9.7 release manager |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood -- the "New Feature" category has merit.
solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc
Outdated
Show resolved
Hide resolved
Update index search document punting of segmentsTerminateEarly to future release
…tiThreaded parameter; (#2596) Co-authored-by: Gus Heck <[email protected]> (cherry picked from commit 7ebbcd3)
…tiThreaded parameter; (#2596) Co-authored-by: Gus Heck <[email protected]> (cherry picked from commit 7ebbcd3) (cherry picked from commit 84d1fbc)
…tiThreaded parameter; (apache#2596) Co-authored-by: Gus Heck <[email protected]> (cherry picked from commit 7ebbcd3) (cherry picked from commit 84d1fbc)
https://issues.apache.org/jira/browse/SOLR-13350
https://issues.apache.org/jira/browse/SOLR-17298