Live data from Hacker News

DNS server in Go - Big NTP Pool upgrade

news.ntppool.org

21–29 of 29 posts

Re: DNS server in Go - Big NTP Pool upgrade

#21
post #15
post #8

I'm in love with Go. The more I use it the more i fall in love with it.

I've seen a number of near-identical comments, but they're not interesting unless you expand on why.

In no particular order:

   - new, shiny, toy (boys will be boys)
   - sufficiently different (allows for think different moments)
   - sufficiently subtle (does promote deep think moments)
   - bipolars are sexy (Go is seriously bipolar.)
   - pedigree (Go is something of a pedagogue)

Re: DNS server in Go - Big NTP Pool upgrade

#22

> Since mid-September, twenty of the name servers have been running the new software and except for a bit of trouble on i386 (32-bit) and low-memory systems, it's been running very smoothly. So is http://code.google.com/p/go/issues/detail?id=909 a real-world problem?

If 32-bit, low-memory machines are part of your world, I would say obviously yes.

Re: DNS server in Go - Big NTP Pool upgrade

#24

> Since mid-September, twenty of the name servers have been running the new software and except for a bit of trouble on i386 (32-bit) and low-memory systems, it's been running very smoothly. So is http://code.google.com/p/go/issues/detail?id=909 a real-world problem?

If 32-bit, low-memory machines are part of your world, I would say obviously yes.

4GB of addressable memory per process is hardly low memory, x32 was recently merged into Linux so I doubt it's going away anytime.

Re: DNS server in Go - Big NTP Pool upgrade

#25
post #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.

Why use such a bad performing server in the first place ? Even 6000 qps is not all that good for a dns server actually.

Even if you do geo lookup on a per /24 basis, surely that doesn't detract that badly ?

Re: DNS server in Go - Big NTP Pool upgrade

#26

For people searching for performance benchmarks like me, here are the numbers I dug around from the post ( http://geo.bitnames.com ) If you need less than 200 DNS lookups per second per DNS server the Perl version is fine and might be a little easier to setup. The Go version is much faster (in prodution we've seen it do 5-6000 requests a second on commodity hardware and even virtual servers). Is 6000 rps a high numbe…

Was it implied that the 6000 requests was peak performance of the software, or was it just the current max usage they've seen?

5-6000 requests was just the number I remembered seeing for sure. I haven't tried pushing the software to get some benchmark number.

It was just on one core (all the production servers are currently just using one core for the geodns process), but the response time was similar to idle load so I think there's lots of head-room

The monitoring doesn't log data at the second granularity and the traffic is very bursty, so the number was just from staring at the real-time monitoring dashboard I have.

Re: DNS server in Go - Big NTP Pool upgrade

#27
post #25
post #7

Earlier quoted context omitted.

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.

Why use such a bad performing server in the first place ? Even 6000 qps is not all that good for a dns server actually. Even if you do geo lookup on a per /24 basis, surely that doesn't detract that badly ?

It's fast enough for now, so investing more time in making it faster would just be spinning wheels.

I haven't done detailed profiling, but the geoip lookup is pretty fast. I think more time is spent picking IPs to return (weighted from a list of sometimes thousands of IPs) and likely more time than that is in the underlying DNS library (which hopefully will get better over time without me doing anything!).

Both the Perl and the Go versions are optimized more for developer time, correctness and robustness over raw performance. I only have so much time to work on it and lots of you depend on it working, so I think those are appropriate trade-offs.

If it was a full-time job more than a hobby maybe it'd make sense to do the work in C instead of Go (but probably not).

Re: DNS server in Go - Big NTP Pool upgrade

#28

Earlier quoted context omitted.

Was it implied that the 6000 requests was peak performance of the software, or was it just the current max usage they've seen?

I suppose it's the latter. That number is pretty much hardware-specific, though it would give us a bit more details if they mentioned the hardware profile.

The DNS servers are (mostly) virtual machines on all sorts of hardware. In many cases I don't actually know the exact hardware specs or how much other load the boxes have.

http://www.pool.ntp.org/dns-server.html

Re: DNS server in Go - Big NTP Pool upgrade

#29
post #18

This seems like a great time to prod more folks into joining the pool. If you have a static IP and a stable machine please consider becoming part of the pool: http://www.pool.ntp.org/en/join.html My firewall at home is part of the pool. You can configure how much traffic you can handle in the manage servers interface. With any decent cable connection you can set the speed to 768Kbit and never notice the traffic (ntp…

Thanks dfc. I made a note for myself to update the site to mention/recommend the pool statement as well:

https://github.com/abh/ntppool/issues/69

Post reply on HN