Testing DNS Performance limits the Final Chapter

Transcription

1 Testing DNS Performance limits the Final Chapter Research by ISC for CAIDA Funded by NSF David Boggs, lead investigator Brian Reid, writer and reporter

2 DNSPERF Project overview Build testbed big enough to test.com,.net TLD service Test its maximum capacity (query rate at server overload point) Reconfigure to use DDNS for updates, IXFR for distribution Test under load, find maximum

3 Physical testbed 13 affordable COTS servers 1 Stealth master for IXFR sourcing Non-blocking GB ethernet Load generator Update generator Monitoring

4 Logical diagram

5 Physical diagram

6 What hardware? Affordable under limited budget ($100K available to buy 16 servers) Candidates: Sun X4200, HP DL140G3, Iron Systems I-class, M- class (Intel Xeon and AMD28x) Must run open-source OS Choose by memory performance

7 Hardware test results L1 Memtest MB/sec LMbench Bandwidt h MB/sec L1 calibrator (NS for miss) LMbench latency (NS) STREAM Copy (MB/sec) STREAM Add (MB/sec) STREAM Triad (MB/sec) HP DL140/G Sun x AMD254 Sun x AMD285 Iron Systems M (AMD) Iron Systems I (Intel) HP Celestica

8 Hardware decision HP DL140/G3 Surprised that Intel processors outperformed AMD for these tests Able to afford 16GB RAM in each (8 pairs of matched 1GB parts)

9 What software? BIND 9.4 OS: Test these, pick the fastest Linux (Gentoo, Fedora), FreeBSD (6, 7), Solaris 10, NetBSD 4, OpenBSD 4.1, Windows 2003 Server, Windows XP Pro64

10 What test? Loaded server with.pt zone Used queries from 48-hour F-Root capture, sent with queryperf Ramped query rate until server limit reached Ran test at server limit for 1 hour (1.13 millioin queries)

11 OS Performance queries/sec Linux-Gentoo Kernel Solaris-10 SunOS 5.11 snv-64a Linux-Fedora Kernel NetBSD 4.0-beta FreeBSD 7-current OpenBSD 4.1-current FreeBSD 6-stable Windows 2003 Server SP Solaris-10 SunOS Windows XP Pro SP FreeBSD 6.2-release Windows 2000 Pro SP

12 Test data stream 48-hour capture from F-Root requests (38.8% failed) Avg rate (req/sec) = %ile burst = Max burst =

13 Test data stream

14 Testing with.com Used COM zone from 5 Oct 2007 Split into 2 parts Each part about 87,000,000 entries One server for each part Raw zone slice file sizes 3GB each

15 New numbers We presented some numbers in November Today s numbers are different. Two sources of differences: COM zone split into slices to fit memory BIND stderr now piped to /dev/null (profiling showed lots of time wasted in console error messages)

16 Testing with COM in 2 slices OS Linux-Fedora FreeBSD-7-RC1 Linux-Gentoo Solaris-10 (Edition of 8/07) Solaris-10 (Edition of 5/07) FreeBSD 6.2-STABLE FreeBSD 6.2-RELEASE NetBSD-4-current Queries/sec average across slices 78,701 75,177 70,223 63,954 61,027 55,866 53,127 32,129

17 Measuring update performance After measuring server performance on fixed zone, we measure rate at which we can update that zone. Updates use RFC2136 protocols and standard BIND tools Update stream was synthetic

18 DDNS updates to COM We sent 10,000 DDNS updates to BIND P1 at maximum speed. Zone being updated was 50% slice of COM, one server per slice. Table shows rate at which updates can be committed to stable storage. We believe the FreeBSD 6.2 anomaly to be a compiler or config bug that omitted fsync calls.

19 COM update rate limits OS FreeBSD-7RC2 FreeBSD-6.2-Stable FreeBSD-6.2-Release NetBSD-4-Current Solaris-10 5/07 ed Solaris-10 8/07 ed Linux-Gentoo Linux-Fedora Slice Slice

20 Final test: query during update Measured performance of COM zone during DDNS update and IXFR. Made slight modification to BIND for this test (disabled periodic write to stable storage, since this is not master copy of zone) Measured for signed and unsigned zones.

21 Notes on the test and results Recall that DDNS updates to COM zone max out around 90/sec So the test sequence 1,2,4,8,16,32,64,128 updates/sec is really 1,2,4,8,16,32,64,90 This test performed only with FreeBSD 7.0-RELEASE

22 Query reply rate of server under update via IXFR Updates / second * Unsigned zone 69,400 67,600 68,100 67,400 60,900 60,408 60,361 Signed zone 61,200 60,100 58,500 58,000 54,900 51,200 50,800 *DDNS updates of master maxed at 90/second

23 Conclusions Open source software and commodity hardware are up to the task of serving large real zones Real-world COM update rates average only 2-4/second, peaked at 10/second during 2006 and Signed zone service is only 10-15% slower than unsigned Slicing a zone for multiple servers works fine. Constant zone update does not significantly degrade server s query-response performance.

24 For more information ISC Tech Note TN ftp://ftp.isc.org/isc/dns_perf/isc-tn pdf Contact to inquire about research access to this testbed (it is available to other researchers)