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
