Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: Stefan Eissing <stefan.eissing@greenbytes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: 2.4.27
Date: Thu, 6 Jul 2017 17:31:31 +0200
References: <19CA5E06-B22D-4A0C-B44F-1017CF1CF6E9@jaguNET.com>
 <20170703173945.cfeauklb6nslkte7@leander>
 <FD8CAA84-C744-491D-8B8C-2741B2DEA86A@jaguNET.com>
 <0e2901d2f667$f7772250$e66566f0$@qqmail.nl>
 <98F14D4D-55E7-43FA-B4F9-EA05E08CA0FA@greenbytes.de>
To: dev@httpd.apache.org
In-Reply-To: <98F14D4D-55E7-43FA-B4F9-EA05E08CA0FA@greenbytes.de>
Message-Id: <FFB62318-3611-4D72-BFC5-780023B4D685@greenbytes.de>
archived-at: Thu, 06 Jul 2017 15:31:40 -0000

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.=20

These are complications not easily debugged or reproducible.

> Am 06.07.2017 um 17:15 schrieb Stefan Eissing =
<stefan.eissing@greenbytes.de>:
>=20
> Hej,
>=20
> 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
>=20
> tl;dr
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> This is not a bug, it is the collision of the processing models.
>=20
> 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.
>=20
> Does this make sense?
>=20
> Cheers,
>=20
> Stefan
>=20
> 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.
>=20
>=20
>> Am 06.07.2017 um 16:55 schrieb Bert Huijben <bert@qqmail.nl>:
>>=20
>>=20
>>=20
>>> -----Original Message-----
>>> From: Jim Jagielski [mailto:jim@jaguNET.com]
>>> Sent: woensdag 5 juli 2017 18:49
>>> To: dev@httpd.apache.org
>>> Subject: Re: 2.4.27
>>>=20
>>> These are just the fixes/regressions noted in CHANGES:
>>>=20
>>> Changes with Apache 2.4.27
>>>=20
>>> *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3.
>>>    PR58188, PR60831, PR61245. [Rainer Jung]
>>>=20
>>> *) 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]
>>=20
>> Can somebody point me to the reasoning behind this?
>>=20
>> I have this configuration on FreeBSD with older Httpd versions, and =
it works
>> just fine for my limited load.=20
>>=20
>> Switching to a different model will require compiling more ports =
myself as
>> the FreeBSD packaging system is optimized for this model.
>>=20
>>=20
>> 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...
>>=20
>> Thanks,
>>=20
>> 	Bert
>>=20
>>=20
>=20