[
https://issues.apache.org/jira/browse/SOLR-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853178#comment-17853178
]
Christine Poerschke commented on SOLR-13350:
--------------------------------------------
Hello again.
{quote}Overall the results could be summarised as "unexpected" or "surprising"
– passing an executor increased latency by around 20x with a reduction in
container CPU use to approximately match that. The thread count used seemed to
make no difference, we've tried a few different ones.
{quote}
{quote}The "just pass an executor" patch was onto a Solr 9.5 cloud, and I
haven't really dived into the details much, but I'm wondering if the
implications for this ticket here might be that searches passing
{{multiThreaded=false}} could be impacted because currently nothing controls
the passing of the executor to Lucene's {{IndexSearcher}} constructor.
{quote}
So the unexpected increase in latency can be explained as follows I think:
* A threadpool executor with {{corePoolSize}} of 0 and {{maximumPoolSize}} of
N and {{queueCapacity}} N*1000 was/is used.
**
[https://github.com/apache/solr/blob/26365679bde2f620b399f7801387e1cbee68cdc5/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L446-L450]
**
[https://github.com/apache/solr/blob/26365679bde2f620b399f7801387e1cbee68cdc5/solr/solrj/src/java/org/apache/solr/common/util/ExecutorUtil.java#L234-L243]
* The
[https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ThreadPoolExecutor.html]
documentation says _"If corePoolSize or more threads are running, the Executor
always prefers queuing a request rather than adding a new thread."_ and _"If a
request cannot be queued, a new thread is created unless this would exceed
maximumPoolSize, in which case, the task will be rejected."_
** With a very generous queue size queuing would have been always possible and
I think that meant we were effectively running single threaded.
Experimentally using a fixed-size threadpool executor i.e.
[https://github.com/apache/solr/blob/26365679bde2f620b399f7801387e1cbee68cdc5/solr/solrj/src/java/org/apache/solr/common/util/ExecutorUtil.java#L198-L202]
removed the slowness (and +very nicely+ improved latency relative to the
pre-experimental baseline).
A fixed-size threadpool executor with an unlimited queue capacity might be
undesirable though, in which case an alternative approach could be to retain
the queueCapacity and to (say) have {{corePoolSize}} match {{maximumPoolSize}}
in value, or something along those lines.
> Explore collector managers for multi-threaded search
> ----------------------------------------------------
>
> Key: SOLR-13350
> URL: https://issues.apache.org/jira/browse/SOLR-13350
> Project: Solr
> Issue Type: New Feature
> Reporter: Ishan Chattopadhyaya
> Assignee: Ishan Chattopadhyaya
> Priority: Major
> Attachments: SOLR-13350.patch, SOLR-13350.patch, SOLR-13350.patch
>
> Time Spent: 11.5h
> Remaining Estimate: 0h
>
> AFAICT, SolrIndexSearcher can be used only to search all the segments of an
> index in series. However, using CollectorManagers, segments can be searched
> concurrently and result in reduced latency. Opening this issue to explore the
> effectiveness of using CollectorManagers in SolrIndexSearcher from latency
> and throughput perspective.
--
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
