Hi Max, I have some good news.
On Thu, Aug 15, 2024 at 06:57:09AM +0200, Willy Tarreau wrote: > Hi Max, > > On Wed, Aug 14, 2024 at 06:21:39AM +0000, Moehl, Maximilian wrote: > > Hi Willy, > > > > > > Is there a similar mechanism in HAProxy? So far I can only see the > > > > static option for the initial window size which comes with the mentioned > > > > drawbacks. > > > > > > There is nothing similar. One of the problems H2 is facing is that there > > > can be application congestion anywhere in the chain. For example, let's > > > say a POST request is sent to a server subject to a maxconn and remains > > > in the queue for a few seconds. We definitely don't want to block the > > > whole connection during this time because we've oversized the window. > > > > > > And there's also the problem of not allocating too many buffers to each > > > stream, or it becomes a trivial DoS. > > > > That makes sense, since we had to accommodate the use-case which triggered > > the > > investigation we increased the window size to 512k as a middle-ground. We > > don't > > usually see congestion on our HAProxies so we are hoping that this does not > > cause any other issues, we'll see once it hits prod. > > There used to be a case where it was causing significant problems: initially > this initial window size was both for frontend and backends. If you were using > H2 on the backend as well, and two requests from different clients were sent > over the same H2 backend connection, a slow reader would be sufficient to > cause the other one to experience read timeouts. Now we've addressed this > using two points: > - it's possible to configure the backend-side window size separately > from the frontend-side > - "http-reuse safe" (the default mode) makes H2 backend connections > private, that is, they're not shared between multiple client > connections. This results in more connections on the backend side > but the progress on the backend matches the progress on the frontend. Now with the current development branch (which will become 3.1-dev10), the streams' rx buffer can now be chained. The principle is that any stream may use any of the up to 100 rxbuf of a 100-stream connection, so that when you're dealing with a single uploading stream on a connection, you can really allocate almost up to 100 buffers to that stream (we always keep a few to create new streams). In my tests with a 100ms server, the performance for a single POST increased from 5 Mbps to 120 Mbps by filling the window. And in order to reach higher speeds, a new option tune.h2.fe.rxbuf allows you to decide how large the per-connection rx memory should be. With 3 MB I'm getting 240 Mbps on a single stream and single connection for example. I invite you to give it a try and report about your tests here. Cheers, Willy
