In principle, I agree w/ making these counters atomic... up to now, some minor discrepancies from "real" has been accepted noise, but the more sophisticated we get, the less we can accept such potential drift.
+1 to both. > On Sep 17, 2018, at 8:44 AM, Rainer Jung <rainer.j...@kippdata.de> wrote: > > I am thinking about making the proxy worker busy count atomic. Currently we > use an apr_size_t in shared memory and increment/decrement simply using the C > ++/-- operators. My (somewhat outdated) experience from mod_jk is, that this > is not necessarily atomic and might lead to missing updates, letting the > proxy worker busy count drift in any direction. > > Since I am also thinking about implementing a busy limit (per proxy worker), > the correctness of the proxy worker busy count would get much more important. > I think such a configurable limit would be really useful, because it allows > some (limited) form of resource management in a reverse proxy, allowing to > define the maximum number of concurrency that is allowed for each worker. > This will prevent the reverse proxy from getting disfunctional when some slow > worker backend starts to consume more and more reverse proxy slots. Not in > all cases can you counter such a scenario with ambigous response timeouts, > which will also kill sporadic slow requests. > > Note that apr atomics are 32 bit counters and current proxy worker busy > counts might be 64 bit depending on platform. But real busy (concurrency) > counters will hardly ever exceeed 32 bit limits. > > Any comments on > > - making proxy worker busy count atomic (using APR atomics) > > - adding a feature to restrict the maximum busyness per proxy worker > > Thanks and regards, > > Rainer
