惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
Securelist
O
OpenAI News
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
T
Threat Research - Cisco Blogs
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Google Online Security Blog
Google Online Security Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
N
News and Events Feed by Topic
S
Security Affairs
SecWiki News
SecWiki News
Project Zero
Project Zero
L
Lohrmann on Cybersecurity
P
Proofpoint News Feed
P
Palo Alto Networks Blog
L
LINUX DO - 最新话题
H
Hacker News: Front Page
Recent Commits to openclaw:main
Recent Commits to openclaw:main
I
Intezer
Simon Willison's Weblog
Simon Willison's Weblog
W
WeLiveSecurity
T
The Exploit Database - CXSecurity.com
K
Kaspersky official blog
The GitHub Blog
The GitHub Blog
I
InfoQ
云风的 BLOG
云风的 BLOG
雷峰网
雷峰网
B
Blog
IT之家
IT之家
AWS News Blog
AWS News Blog
Jina AI
Jina AI
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Google DeepMind News
Google DeepMind News
Spread Privacy
Spread Privacy
N
News and Events Feed by Topic
Security Latest
Security Latest
美团技术团队
C
Check Point Blog
WordPress大学
WordPress大学
T
Tenable Blog
S
Security @ Cisco Blogs
Last Week in AI
Last Week in AI
博客园 - 聂微东
月光博客
月光博客
博客园 - 【当耐特】
S
Schneier on Security
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
S
Secure Thoughts
Schneier on Security
Schneier on Security
C
Cisco Blogs
Cyberwarzone
Cyberwarzone

CoreDNS: DNS and Service Discovery

redis_cache kubernetes log proxyproto rewrite CoreDNS-1.14.2 Release forward CoreDNS-1.14.1 Release CoreDNS-1.14.0 Release clouddns errors grpc_server https https3 template docker auto geoip multisocket nomad CoreDNS-1.13.2 Release dnstap import view CoreDNS-1.13.1 Release CoreDNS-1.13.0 Release ready etcd header loadbalance CoreDNS-1.12.4 Release bind grpc CoreDNS-1.12.3 Release file prometheus quic timeouts CoreDNS-1.12.2 Release kubeforward CoreDNS-1.12.1 Release JSON gslb autopath dnssec root tls CoreDNS-1.12.0 Release CoreDNS-1.11.4 Release fanout CoreDNS-1.11.3 Release k8s_cache CoreDNS-1.11.2 Release CoreDNS: DNS and Service Discovery bufsize k8s_external reload CoreDNS-1.11.1 Release CoreDNS-1.11.0 Release gathersrv meship meshname CoreDNS: DNS and Service Discovery multicluster acl cache recursor CoreDNS-1.10.1 Release CoreDNS-1.10.0 Release health trace tsig CoreDNS-1.9.4 Release k8s_event redis CoreDNS-1.9.3 Release CoreDNS-1.9.2 Release route53 CoreDNS-1.9.1 Release CoreDNS and Apache APISIX open new doors for Service Discovery? Trail Of Bits Security Review CoreDNS-1.9.0 Release dns64 transfer finalize kubenodes CoreDNS-1.8.7 Release ebpf CoreDNS-1.8.6 Release rrl secondary CoreDNS-1.8.5 Release CoreDNS: DNS and Service Discovery mysql warnlist CoreDNS-1.8.4 Release loop minimal sign CoreDNS-1.8.3 Release
CoreDNS Performance Testing
miek · 2017-08-09 · via CoreDNS: DNS and Service Discovery

As CoreDNS is an inception level project under the CNCF which means we have access to the physical cloud infrastructure of Packet, a bare metal(!) cloud provider. Physical machines imply performance and also because you get an entire machine you can use them for performance metrics.

For CoreDNS we have a few Benchmark tests (from the Go standard library) that haven’t seen much use. Typically you run these before your change and then after your and then use a tool like benchcmp to compare the results and impress your PR’s reviewers. This is all pretty manual, a more automated (and visual!) way would be welcome.

Our new Packet machines to the rescue. We’ve setup the following work flow:

GitHub > webhook > mbench > prometheus > grafana

I.e. we configured a webhook that gets triggered on a pull request and then via some Caddy proxy trigger gets delivered to webhook. Webhook then kicks of a shell script, that pulls down CoreDNS’ repo and the correct pull request. ^[Yes, this script parses the JSON with grep, ultimately that was the only way to make it reliably work.]

This benchmark script does nothing more than run the bench mark tests: go test -run='' -bench=. -benchmem ./... 2>/dev/null).

The output from these tests, i.e:

BenchmarkRequestDo-8   1000000000	 2.11 ns/op	  0 B/op    0 allocs/op

… is written into the named pipe which is then picked up by mbench and converted into Prometheus metrics:

2017/06/25 09:21:51 [INFO] Parsed line: {branch="pr-753",cpu="8",subsystem="coredns"}requestdo_coredns: 1000000000 2.110000 0 0

The latest known branches are found by using a “recording rule” that uses an extra metrics that mbench exports: _start_time_seconds: So we only see the active branches from the last n branches:

benchmark_coredns_branches_topk10 = topk(10, benchmark_coredns_cacheresponse_start_time_seconds{branch != "master"})

There is also cron.hourly that tests master on a continuous basis, which we display separately in Grafana.

Grafana

In Grafana, for each defined benchmark, we’ve setup a templated dashboard: benchmark_coredns_[[benchmark]]_run_gauge{branch=~"$branch"}:

Branch and benchmark selectors in Grafana.

So we can easily select that branch and compare it with whatever other branch.

Thus in the end leading to a dashboard where you can easily compare your performance against the master branch: https://snapshot.raintank.io/dashboard/snapshot/0er0u40KAZ1YM4dl0KgDUkeD3KhzZqFj

Benchmark dashboard.

The end result of all this is that if someone adds an optimization it will be immediately visible in the stats. Any new pull request shows up automatically and any new benchmark function will also be automatically discovered.