You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rainer Jung <ra...@kippdata.de> on 2018/09/17 12:44:51 UTC
Making proxy "busy" atomic and implement a busy limit
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
Re: Making proxy "busy" atomic and implement a busy limit
Posted by Jim Jagielski <ji...@jaguNET.com>.
FYI: Both clang and GCC support both __sync and __atomic which support 64bit ints. We could add that functionality to APR...
> On Sep 17, 2018, at 8:57 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> 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 <ra...@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
>
Re: Making proxy "busy" atomic and implement a busy limit
Posted by Jim Jagielski <ji...@jaguNET.com>.
FYI: Both clang and GCC support both __sync and __atomic which support 64bit ints. We could add that functionality to APR...
> On Sep 17, 2018, at 8:57 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> 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 <ra...@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
>
Re: Making proxy "busy" atomic and implement a busy limit
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ra...@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