Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
8.0
-
None
Description
Ever since the Http2SolrClient was introduced, if the client was set up to use http2, then the maxConnectionsPerDestination was hardcoded to 4 and could not be overridden.
This may have been due to a mis-reading of the setMaxConnectionsPerDestination javadocs whichs states that browsers generally use 2-6 requests per destination, and links to an RFC. However the RFC linked to covers HTTP 1.1 and obviously Solr is not a browser.
A number of users have seen issues around slowness when using http2, and I think this is a likely cause. Http2 will multiplex requests on a single connection, however by default the number of requests that Jetty will multiplex is somewhere around 300. (This is a very hard value to track down, as the way it is determined is via a web of indirection)
So, for example, the HttpShardHandler defaults to 100,000 maxConnectionsPerDestination. So the users using http1 will be able to get that throughput. The users using http2 will have a max of roughly 1,200 (4 * 300). Obviously there is going to be a massive performance implication.
So I think we should just use the same maxConnectionsPerDestination for both http2 and http1. The http2 client will have the added benefit of using multiplexing, and Jetty will likely do the right thing and not create tons of connections when multiplexing can be used instead.
Attachments
Issue Links
- relates to
-
SOLR-16932 Http2Client should have configurable `maxOutstandingRequests`, to support parallel requests in high-shard-count contexts
- Open
- links to