> 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. Regards, - HÃ¥vard _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users