httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: about those async filters
Date Thu, 08 Oct 2015 11:53:19 GMT
On 08 Oct 2015, at 1:23 PM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:

> I am very happy to get such feedback and start thinking about how to make the http/2
integration tighter. As it is designed now, it was intended to fit into a 2.4.x server which
limited several design decisions and resulted in the separate worker pool. Since HTTP/2 changes
the processing model for a server (unless you just reverse proxy it in front of the http/1
engine), not all existing parts will fit unchanged.

As I already pointed out, the reasons for the existing design are understood - however one
big limitation is now lifted, and that is with mod_http2 being in the httpd core, mod_http2
has the opportunity to make the changes it needs to the core to lift whatever limitations
existed before. Subject to our normal backport rules, we have the opportunity to make these
changes available to the wider server in v2.4.

> What you are currently sketching below is that http2 workers need to become one with
the mpms and I very much agree. What you described with the socket pairs however sounds much
more like a in-process reverse proxy. That, I think, is not so fantastic.
> 
> For example, a lot of use cases serve static files and for best performance - I think
- we need to directly write the file, chunked as needed by the transport, onto the outgoing
connection. So, the file bucket (or the handle itself) should find its way from the slave
to the master connection. This is what mod_http2 already achieves.

Right now one use case - static files - is being prioritised at a significant detriment to
the operation of the rest of the server, and this is far from ideal.

There are solutions to the file buckets problem, it is quite possible to provide a mechanism
to tunnel file descriptors from the slave connection to the master. I don’t see this as
a blocker.

> Jim invented the slave connections in trunk, where the relation ship between master and
slaves is visible to all. This is nice. I could not use them for the 2.4 approach and I think
there are some multi-threading issues around pool reclaiming open... But ultimately, the existence
of slave connections will become visible to a lot of parts of the server and pretending that
we still live in http/1 land becomes harder and harder (or affords more and more compromise).

As I said about the HTTP/1.1 emulation on the slave connections, I’m not sure if it’s
workable. Either way it’s not critical, as long as the correct handler steps up to process
the slave connections we will be fine.

> HTTP/2 on https:// connections, as reported by Firefox, is currently at ~30% of requests.

We need to make sure we haven’t made a step backwards in the core of the server. The event
MPM solved the C10k problem for file handling, and the async filters generalises this to all
filters (most critically SSL) and all types of content. We need to make sure that mod_http2
doesn’t undo that work and make requests synchronous again.

Regards,
Graham
—


Mime
View raw message