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 is just tiny udp datagrams).
While we are at it lets go through /etc/ntp.conf and remove any references to stratum one servers. With a recent version of ntp you can replace all of your server lines with:
pool 0.CC.pool.ntp.org iburst
pool 1.CC.pool.ntp.org iburst
pool 2.CC.pool.ntp.org iburst
pool 3.CC.pool.ntp.org iburst
pool CC.pool.ntp.org iburst
More info on using the pool can be found here:
So is http://code.google.com/p/go/issues/detail?id=909 a real-world problem?
So, I guess your sarcasm was a bit too subtle. This one is better :)
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 number for a DNS server? Let me do a back of the envelope calculation: one simple dns request (assuming udp here) response msg size is 100bytes, 6000rps x 100bytes /1024/1024 x 8 = 4.69mbps. Even we consider the request msg size is equal to that of response msg, the throughput is still 9.38mbps, far from saturating the network pipe. It sounds to me there is still space for improvement.
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.
- 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)
thanks for sharing.
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.
Even if you do geo lookup on a per /24 basis, surely that doesn't detract that badly ?
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).