exporter impact on my dns bind performance

[kaiwisdom]

this is my environment:
bind version: 9.10.7
bind_exporter: version 0.2.0-dev (branch: master, revision: fdbe49f)
go version: go1.9.4
pull_interval: 1m

test via go program :
startDomain := time.Now()
_, err := net.LookupHost("test.com")
elapsed := time.Since(startDomain)

in every same interval time ,i find client query is very slow than other time ,query time about is 100ms ， and this time is monitor pull data；

[grobie]

Unfortunately we at SoundCloud have experienced the same, even in newer versions and the API v3. Pulling statistics impacts the latency of client requests, presumably due to locking. We've since replaced bind with CoreDNS at our edges to improve the long-tail latency.

[dswarbrick]

Out of curiosity, do you think the JSON stats endpoint supported by BIND 9.10+ has any less impact than the XML endpoint?

[SuperQ]

Has any of the newer upstream bind releases improved this situation?

[SuperQ]

I've been doing a few tests on bind 9.11.5. It seems like the tasks endpoint is the slowest, it also doesn't seem to produce that many useful metrics. It looks like it was enabled by default with #50.

But the impact on the server is pretty big, the scrape time goes up by ~800ms.

bind_tasks_running 1
bind_worker_threads 32

The JSON output does seem a little faster in some of my local curl tests, it might be worth implementing support for it to compare against the XML format.

[yjlmzh]

我一直在对绑定9.11.5进行一些测试。tasks端点似乎是最慢的，它似乎也没有产生那么多有用的指标。似乎默认情况下已使用＃50启用它。

但是对服务器的影响很大，抓取时间增加了约800毫秒。

bind_tasks_running 1
bind_worker_threads 32

在我的某些本地curl测试中，JSON输出的速度似乎更快一些，可能值得实现对其进行支持以与XML格式进行比较的支持。

hi Using JSON, you can avoid this problem.
curl 127.0.0.1:8053/json
Then observe the single thread CPU usage. Or dig parsing time. Basically no effect
When will the JSON channel be supported 😂

[dswarbrick]

Refs #82

[SuperQ]

Closing this in favor of #82.