[
https://issues.apache.org/jira/browse/SOLR-17665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926214#comment-17926214
]
Houston Putman commented on SOLR-17665:
---------------------------------------
Yeah, I have been looking into this, and there really isn't a great way forward
as is. We need to create (or cache I guess) IndexSearchers for the given
TaskExecutor and timeouts going forward (Our current timeout approach is
deprecated). I don't like the idea of creating an indexSearcher per-request,
however I bet most queries will follow a certain set of inputs (timeout &
taskExecutor) such that per-core, we won't end up with too many.
I do think that this can (and should) be separated from the SolrIndexSearcher,
probably. Or at least the SolrIndexSearcher can become a lot leaner and use
Lucene in a more modern way.
> Perf regression: overhead of multiThreaded=false should be nothing
> ------------------------------------------------------------------
>
> Key: SOLR-17665
> URL: https://issues.apache.org/jira/browse/SOLR-17665
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 9.7
> Reporter: David Smiley
> Priority: Major
> Attachments: flight-9.8-executor-disabled.jfr,
> flight-9.8-mt-false-executor-enabled.jfr, flight-9.8-mt-true.jfr
>
>
> SOLR-13350 introduced {{multiThreaded}} query param, defaulting to false,
> thus opt-in. But there is still a serious performance impact; only setting
> {{indexSearcherExecutorThreads}} to -1 in solr.xml mitigates the regression.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
