On Fri, Mar 11, 2016 at 11:33 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > >> Am 10.03.2016 um 22:24 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> [...] >>> >>> Concurrent Handling >>> ------------------- >>> I was then thinking: how do I get all the concurrent proxy_http2 requests to >>> use the same connection? I was originally thinking about some dort of >>> de-mux, >>> a sort of concentrator that sits on a single connection and communicates >>> with >>> all the worker threads that have proxy requests... >>> >>> But that would be insane! There would be one worker sitting on the master >>> connection, several workers for each single proxy request and one more >>> worker that sits on the backend connection. And all the proxy requests >>> would do is move data from the master connection thread to the backend >>> one and vice versa. But what we need is just 2 workers: one for the master >>> connection and one for the backend connection. They should handle as many >>> concurrent requests as configured! >> >> Hmm, I'm not sure to follow here. >> I read this as no need for workers because after all we don't need h1 >> requests to forward h2. > > That is not what I meant. I'd like to draw some pictures, but ASCII art > in emails... I give this a try ;-)
Sorry, I misunderstood what you meant in the first part, and somehow realized that by reading further (just leaved my first comments to be at ease with nice explanations and ascii art you do so brilliantly :) That's even clearer now, thanks! > >> But proxying is not only about routing, it's also rewriting, caching, >> filtering, securing..., so who would do that actual work per request >> if not workers? > > If I understand you correctly, all this is still happening. The things > I describe above are only happening when the handler of mod_proxy_http2 > is invoked to open the backend connection. > > I assume caching, rewriting etc. happens before that? Yes, all h1 stuff should work out of the box ;) >> That's pretty much what the MPM (event) does, let's make it available >> for backend connections (there is some code like this alredy in >> mod_proxy_wstunnel which makes use of SUSPENDED and MPM callbacks, >> that may be a way). > > Yes, that makes sense. Maybe we can go even further and make the > whole request processing not rely on the stack so much. Then we could > suspend/resume more often and, as I understand it, that is what > Graham is working for also. Yes, I'm looking forward Graham's work too. Re. suspend/resume, we'll need to take care of thread/context switches as much as possible (i.e. not waking threads for small chunks), possibly by setting buckets aside until significant/whole data is available, plus batching. > > (Comments on the rest in another mail) Going there now...
