Hi Clemens, Solrj clients are thread-safe singletons, from my experience the strategy you are using works well even under high load, when calls to Solr take seconds to answer usually it happens because of the number of the queries, the kind of queries (grouping or too many facets) or even for garbage collection problems. Why do you think that this problem is caused by the wrong usage of the clients?
On Mon, May 30, 2022 at 8:30 AM Clemens WYSS (Helbling Technik) < [email protected]> wrote: > We have a non clustered single (8.x) Solr server setup and use SolrJ to > connect our tomcat to the Solr server. Under high load (e.g. last black > friday) we face a bottleneck due to our webapp-search-requests. Calls to > solr take seconds, dangling http-connecitons, ... > Firing the same ( or even way more ) search requests directly onto our > Solr server showed, as expected, no problem. Therefore my implication is > that SolrJ/HttpSolrClient/HttpClient is not setup as expected. > Our search API is setup alike: > > private final Map<String, SolrClient> coreConnections; // one SolrClient > per core > ... > > // create a new SolrClient for a core if not existant > HttpSolrClient.Builder builder = new HttpSolrClient.Builder( coreUrl ); > solrClient = builder.build(); > coreConnections.put( key, solrClient ); > > As you can see > * we keep one SolrClient-connection per core in a map and make use of > these connections > * making use of HttpSolrClient ( Http2SolrClient is denoted "experimental" > and has cause some problem ) > * no special tweaking of underneath HttpClient > > Any reason for this minimal setup not being able to stem many many > concurrent requests? What is the proposed SolrJ based solr client setup > (for a single Solr server)? > > Thx > - Clemens > -- Vincenzo D'Amore
