On Fri, Aug 24, 2018 at 1:05 PM Jim Jagielski <[email protected]> wrote: > > > > On Aug 24, 2018, at 12:05 PM, Eric Covener <[email protected]> wrote: > > On Fri, Aug 24, 2018 at 11:57 AM Christophe JAILLET > <[email protected]> wrote: > > > Le 24/08/2018 à 16:40, Jim Jagielski a écrit : > > I was wondering if someone wanted to provide a sanity check > on the above PR and what's "expected" by the health check code. > > It would be very easy to adjust so that hcinterval was not > the time between successive checks but the interval between > the end of one and the start of another, but I'm not sure that > is as useful. In other words, I think the current behavior > is right (but think the docs need to be updated), but am > willing to have my mind changed :) > > Hi Jim, > > the current behavior is also what I would expect. > If I configure a check every 10s, I would expect 6 checks each minute, > even if the test itself takes time to perform. > > > > Bug describes something else IIUC. Because the watchdog calls us 10 > times per second, it continuously sees that the worker hasn't been > health checked within the desired interval and queues up a check, it > doesn't know one is queued. > > > But that is only an issue, afaict, if the time taken to do the health check is > greater than the interval chosen... Or am I misunderstanding? That is, > if the interval is 200ms, and the health check takes 100ms, all is fine, we > get 5 checks a second.
I don't think it's hc execution time relatve to interval, it's hc execution time relative to AP_WD_TM_SLICE. If it's much more than AP_WD_TM_SLICE they'll stack up while one is running. For a 1 second response you could queue up 10 in a second even if you only have an interval of as minute or hour.
