On Mon, 20 Jun 2022 at 11:24, Stefan Eissing <ste...@eissing.org> wrote:
> I would like to move the h2 worker pool into the mpm at some time in the > future. To be available on systems with threads and non-prefork > configurations. > > The main motivation for this is that h2 workers have been so far "under > the hood" of mod_http2. This makes them invisible to other parts of the > system, like the scoreboard. > > On public fronting installations, h2 is now according to browsers and > CDNs, outnumbering h1. This means their configuration has become more > relevant and user need a way to monitor those. > > Also, should anyone ever start to tinker with a h3 implementation, such a > worker pool would also become necessary. I think this should be a single > instance. Duplicate pools for request processing do not make sense. > > > > Why a separate pool at all? Do not the mpms already have a worker pool? > > Yes, but we are not fully async. This means that an active worker on a > primary connection is firing off many secondary connections to process. > Would we try to run them in the same pool, we'd encounter deadlocks. Also, > dimensioning would become difficult. Example: > > An mpm_event with 10 workers, 9 active TCP connections running. > - this leaves 1 worker to handle the actual requests of 9 connections. > Performance will be bad. > - the mpm would accept a 10th connection and leave no worker available for > secondary requests. The system stalls until timeouts trigger. > > This is avoided by using separate pools for primary and secondary > connections. One could still encounter stalls with an under-dimensioned > second pool, but it can be more easily and transparently managed. We should > give the admin tools to monitor this second pool in the scoreboard, of > course. > > Hi Stefan, I agree that h2 workers should be part of MPM: MPM already knows how thread it creates for connections and should manage all threads in process. The interesting question is what API would be suitable to implement for different MPM. Can we use something like implemented by APR threadpool: threadpool_task_push() threadpool_task_cancel() threadpool_task_schedule(apr_interval_t) ? -- Ivan Zhakov
