Strange recursor response time pattern
he at uninett.no
Thu Sep 7 13:02:57 UTC 2017
> It would be difficult, and possibly impossible, to continue to
> process queries and format a report on queries simultaneously
> without losing information in the report. To have a separate
> thread creating the report, it might have to stop query
> processing, take a snapshot of the data at that point in time,
> save it somewhere, restart query processing, and then format
> the report from the saved data. In this case, there would be a
> brief interval when name could not handle queries.
> One might have to write a prototype to determine how long that
> interruption would take.
Possibly, yes. I can't presently answer to the internal workings of
BIND to give an educated guess as to how much time the "take
snapshot of stats raw data" function would take, and as you say that
might need to be prototyped. However, it can hardly be worse than
what is there today, where the stats processing thread gets queries
queued to it while it's busy doing all the stats processing, and
meanwhile not answering any of the queued queries.
I'll note that unbound, when subjected to execution of
"unbound-control stats" every 10 seconds does not behave the way
BIND does. Admittedly, the number of stats values you get from
unbound is far, far smaller than what we get from BIND.
More information about the bind-users