Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Flow control in AsyncMiddleManServlet

Hi,

On Wed, Feb 20, 2019 at 12:59 AM Raoul Duke <rduke496@xxxxxxxxx> wrote:
> One follow-up question.  It occured to me that it may be an option to use HTTP/2 on the upstream connection and I wanted to ask you if that would be in any way helpful in the situation I am in?  for example: would it be reasonable to expect there would be less contention for the (conceptually discussed) 100 upstream threads if those requests could be multiplexed over existing backend connections (rather than each connection being head-of-line "blocking" on a particular PUT operation to complete before the connection can be used by another PUT as in HTTP/1.1).
>

HTTP/2 is a beast on its own.

While it is true that you can multiplex requests onto a single
connection, it is also true that you have to play nice with HTTP/2
flow control. This is usually a huge bottleneck, but if you can
control the server and the client, you can enlarge their values to fit
your needs.
I would not recommend to use just one connection to the server: we
have seen good effects if we can parallelize the HTTP/2 traffic onto
multiple connections. Certainly not the number of connections that
HTTP/1.1 requires, but there is no point to insist on having just one.

HTTP/2 also typically requires stronger encryption, so you may have to
pay some additional cost there.

For your case, if your numbers are really 100 concurrent requests,
then you may be ok at multiplexing them onto one or few connections.
In general, however, both a HTTP/2 client and a HTTP/2 server will
impose a limit on the max number of concurrent streams, so you may
still hit head-of-line blocking if you saturate them all - though much
later than HTTP/1.1.
Imagine you can multiplex 50 requests per connection, you have 3
connections available, you are queueing the 151st concurrent request
(while in HTTP/1.1 you would be queueing the 4th concurrent request).

In general we have seen better performance, reduced CPU and less
resources used when using HTTP/2 in a proxy (or similar) scenario, so
we typically recommend it although it needs more careful tuning.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.


Back to the top