Correction: websockets are not defined over h2. To make a more "real life" scenario:
One example is a long polling request by a javascript component. During the long poll, the browser will not get other responses. More esoteric: when content filters (brotli, gzip) are in place, compression happens in the h2 worker thread. If one PUSHes such a resource, clients sometimes use h2 flow control to delay the sending of a response. This would deadlock the connection in a prefork model. These are complications not easily debugged or reproducible. > Am 06.07.2017 um 17:15 schrieb Stefan Eissing <[email protected]>: > > Hej, > > I tried to gather some discussion about this. Should have polled this mailing > list. You can read most of it here: https://github.com/icing/mod_h2/issues/142 > > tl;dr > > I had several reports in the past of people being disappointed about h2 > performance, only to learn they were on prefork. Which means every request is > processed serially (with static files being an exception, as long as no > filters prevent this). > > In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers, which > brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in the > config and you have the pre-2.4.26 behaviour. > > Regardless of the discussion if the change in 2.4.26 was reasonable or not: > it is not possible to map the prefork single-thread requirement on to HTTP/2. > Not going to work. One long running request, one websocket opened, and your > browser will stall. > > This is not a bug, it is the collision of the processing models. > > So, I think disabling it prevent user from shooting themselves in the foot. > If you are on prefork, you'd want the 6 parallel HTTP/1.1 connections, not h2. > > Does this make sense? > > Cheers, > > Stefan > > PS. Yes, I know that one /could/ make parallel processes work in prefork by > placing the h2 dispatching in a parent process. If someone wants to implement > that, be my guest. > > >> Am 06.07.2017 um 16:55 schrieb Bert Huijben <[email protected]>: >> >> >> >>> -----Original Message----- >>> From: Jim Jagielski [mailto:[email protected]] >>> Sent: woensdag 5 juli 2017 18:49 >>> To: [email protected] >>> Subject: Re: 2.4.27 >>> >>> These are just the fixes/regressions noted in CHANGES: >>> >>> Changes with Apache 2.4.27 >>> >>> *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3. >>> PR58188, PR60831, PR61245. [Rainer Jung] >>> >>> *) mod_http2: disable and give warning when mpm_prefork is >>> encountered. The server will >>> continue to work, but HTTP/2 will no longer be negotiated. [Stefan >> Eissing] >> >> Can somebody point me to the reasoning behind this? >> >> I have this configuration on FreeBSD with older Httpd versions, and it works >> just fine for my limited load. >> >> Switching to a different model will require compiling more ports myself as >> the FreeBSD packaging system is optimized for this model. >> >> >> I do understand that there is a better mapping of http/2 streams with the >> more modern MPMs, but there must be a reason that it worked and no longer >> can be supported in the future. I assume this reason is already documented >> somewhere... >> >> Thanks, >> >> Bert >> >> >
