Hi, On later 8.x versions, Http2SolrClient is no longer experimental and would be the preferred one since it uses a HTTP2 connections. Such high-load bottlencks may be hard to diagnose, so you'd likely need to profile your Tomcat webapp and look for signs of what is happening, such as timeouts, threadpool starvation etc.
Jan > 30. mai 2022 kl. 08:30 skrev Clemens WYSS (Helbling Technik) > <[email protected]>: > > 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
