Joining the chorus of people looking at this benchmark. I debated on replying on the original thread but see that this one is most up-to-date.
I can reproduce some of the behavior mentioned in this thread and the earlier one on the subject. Most notable observations: 1. Disabling the Executor via indexSearcherExecutorThreads=-1 brings back "good" performance of 9.6 2. Enabling the Executor (default threads set to available cores) with multiThreaded=true increases latency of the benchmark by at least 4X. It's worth noting that the benchmark sends these queries one at a time so the CPU is under-utilized and any theoretical benefits of parallelization are not realized. 3. Enabling the executor (default threads set to available cores) with multiThreaded=false also increases latency of the benchmark. Thanks David for starting the discussion on issue #3 specifically in the JIRA: https://issues.apache.org/jira/browse/SOLR-17665. I've added my own comments to this as well as some JFR recordings which I hope might be helpful in getting to the bottom of what is going on. From: dev@solr.apache.org At: 02/11/25 15:35:47 UTC-5:00To: dev@solr.apache.org Subject: Re: Identifying performance issues in Solr 9.7/9.8 Changing the solr.xml seems to solve the issue: - Solr 9.8.0 (indexSearcherExecutorThreads=-1): Search time, ms: 137 5 9 10 3 3 6 2 2 2 3 0 1 2 1 1 2 2 1 5 From: dev@solr.apache.org At: 02/11/25 13:52:12 UTC-5:00To: dev@solr.apache.org Subject: Re: Identifying performance issues in Solr 9.7/9.8 I filed a JIRA: https://issues.apache.org/jira/browse/SOLR-17665
