osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making proxy "busy" atomic and implement a busy limit


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 <jim@xxxxxxxxxxx> 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 <rainer.jung@xxxxxxxxxxx> 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
>