httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: 2.4.27
Date Thu, 06 Jul 2017 17:10:51 GMT
It starts with a one time warning and will not negotiate. That's all. 

> Am 06.07.2017 um 19:02 schrieb William A Rowe Jr <wrowe@rowe-clan.net>:
> 
> +1 to removing support of mom prefork. I'd prefer it still start and if configured, with
an [error] level alert in the logs and simply be disabled. Server must start when module is
loaded but not configured, e.g. in test framework, IMO.
> 
>> On Jul 6, 2017 10:31 AM, "Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
>> 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 <stefan.eissing@greenbytes.de>:
>> >
>> > 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 <bert@qqmail.nl>:
>> >>
>> >>
>> >>
>> >>> -----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
>> >>>
>> >>> 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
>> >>
>> >>
>> >
>> 

Mime
View raw message