Live data from Hacker News

DNS server in Go - Big NTP Pool upgrade

news.ntppool.org

1–10 of 29 posts

Re: DNS server in Go - Big NTP Pool upgrade

#4
post #3

[deleted]

It is a well known practice. In this case, you can easily load the same configuration and replay the same queries on the Perl and Go servers, then compare. This means that you have only a single component to test. Supposing the author had selected a different configuration format, he would have had to also check that the configuration was correctly created and loaded. It also allowing the author to put a single server in production to load test once the preliminary tests give good results.

Re: DNS server in Go - Big NTP Pool upgrade

#5
Miek Gieben's [1] DNS library [2] is truly excellent. I use it at Port 6379 for an authoritative DNS server, looking up Redis instances [3]. I too have found Go surprisingly productive and enjoyable to code, and our servers seem very stable so far.

[1] http://www.miek.nl/

[2] https://github.com/miekg/dns

[3] https://port6379.com/blog/2012/09/03/using-dns-to-find-insta...

Re: DNS server in Go - Big NTP Pool upgrade

#6
post #4
post #3

[deleted]

It is a well known practice. In this case, you can easily load the same configuration and replay the same queries on the Perl and Go servers, then compare. This means that you have only a single component to test. Supposing the author had selected a different configuration format, he would have had to also check that the configuration was correctly created and loaded. It also allowing the author to put a single serve…

It also makes it much easier to roll back to the previous implementation. If he had created a new configuration file format, he'd have to keep the old and new config files in sync until the new implementation had proven out. Speaking from similar experience, that's no fun.

Re: DNS server in Go - Big NTP Pool upgrade

#7
post #3

[deleted]

You read it wrong.

Try this: the new software reads the old config file format, so we can stagger the roll-out (install new code on some servers while keeping the old code on other servers), and expect things to keep humming along with no downtime and a simple fallback procedure if we see any problems. The new code should perform better than the old code, that's why we wrote it.

Post reply on HN