httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: 2.4.27
Date Thu, 06 Jul 2017 17:02:56 GMT
+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