httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Balancer persist and inherit stuff in trunk
Date Wed, 09 Jan 2013 14:15:25 GMT
Fixed in r1430821
On Jan 9, 2013, at 8:45 AM, Jim Jagielski <jim@jagunet.com> wrote:

> That seems to be an issue w/ slotmem... looking into
> it.
> 
> 
> On Jan 9, 2013, at 7:26 AM, Rainer Jung <rainer.jung@kippdata.de> wrote:
> 
>> On 08.01.2013 17:09, Jim Jagielski wrote:
>>> Rainer, does the below address your concern and make
>>> it OK that the current behavior acts the way it does
>>> and we're OK to keep it that way.
>> 
>> Yes sort of. We now know/remember why there are subtleties and since
>> some statistical counters are dual purpose - statistics/monitoring and
>> LB decision data it seems we need to give up a 100% consistency goal.
>> I'm OK with that as it is now.
>> 
>> Did you have a look at the other topic about the "Used" shm slot counter?
>> 
>> Regards,
>> 
>> Rainer
>> 
>>> On Jan 8, 2013, at 10:25 AM, Jim Jagielski <jim@jaguNET.com> wrote:
>>> 
>>>> Yeppers...
>>>> 
>>>> actually, transferred and read *are* persisted, it's just
>>>> that the bytraffic lbmethod is smart enough to know that
>>>> when the config is changed, those counters need to
>>>> be reset and, by default, a restart is a "change".
>>>> Since elected is never used for any sort of lbmethod,
>>>> it never is reset and so the persist "holds".
>>>> 
>>>> So the idea is that lbmethods should reset any potential
>>>> persisted values iff it makes sense for that lbmethod.
>>>> bytraffic resets transferred/read but byrequests doesn't,
>>>> for example.
>>>> 
>>>> On Jan 8, 2013, at 9:49 AM, Jim Jagielski <jim@jagunet.com> wrote:
>>>> 
>>>>> Hold on a tic... let me go thru my notes. I seem to recall
>>>>> an issue I hit.
>>>>> 
>>>>> On Jan 8, 2013, at 9:28 AM, Jim Jagielski <jim@jaguNET.com> wrote:
>>>>> 
>>>>>> +1 for both being reset...
>>>>>> 
>>>>>> On Jan 7, 2013, at 4:40 AM, Rainer Jung <rainer.jung@kippdata.de>
wrote:
>>>>>> 
>>>>>>> On 06.01.2013 17:48, Jim Jagielski wrote:
>>>>>>>> I had thought that I has responded to that orig
>>>>>>>> email that both below issues where "by design"
>>>>>>>> but could be adjusted if need be or desired.
>>>>>>>> 
>>>>>>>> I have no opinions either way, but to be Used seems
>>>>>>>> more session based and Elected is more long-term
>>>>>>>> statistical.
>>>>>>> 
>>>>>>> Hmmm, but the "Used" field should give information about shm
slots
>>>>>>> occupied by configured balancers. Isn't the info (=0) wrong after
a restart?
>>>>>>> 
>>>>>>> Concerning the long term statistical values I'm undecided like
you, but
>>>>>>> I think we should handle them in a consistent way, so "traffic"
and
>>>>>>> "elected" should either be both persisted or both reset.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Rainer
>>>>>>> 
>>>>>>>> On Jan 5, 2013, at 1:41 PM, Rainer Jung <rainer.jung@kippdata.de>
wrote:
>>>>>>>> 
>>>>>>>>> On 04.01.2013 19:48, Jim Jagielski wrote:
>>>>>>>>>> Have people had a chance to test, review and try
the balancer
>>>>>>>>>> persist and inheritance stuff in trunk? I want to
make
>>>>>>>>>> sure that we have some level of verification and
agreement
>>>>>>>>>> there before I work on the backports for 2.4 ;)
>>>>>>>>> 
>>>>>>>>> I didn't see any changes with respect to two of my original
comments:
>>>>>>>>> 
>>>>>>>>> The "Used" counters (number of shared mem slots) in balancer
manager
>>>>>>>>> drops to "0" after restart/reboot´with persist on. This
seems strange.
>>>>>>>>> Not that "Used" does *not* have anything to do with request
counting.
>>>>>>>>> 
>>>>>>>>> Second the "Elected" counter is persisted but e.g. the
traffic counter's
>>>>>>>>> not. This seems somewhat inconsistent. I have no strong
opinion whether
>>>>>>>>> to persist statistics or not, but we might want to behave
consistently.
>>>>>>>>> 
>>>>>>>>> I did not observe any functional changes after my Mail
from Dec. 14, right?
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> 
>>>>>>>>> Rainer
>> 
> 


Mime
View raw message