On 08 Oct 2015, at 1:23 PM, Stefan Eissing <stefan.eiss...@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 —
