Date: Wed, 13 Sep 2006 18:27:11 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Marcelo Gardini do Amaral <marcelo@registro.br> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: DNS query performance Message-ID: <20060913182457.W50147@fledge.watson.org> In-Reply-To: <20060913182019.R50147@fledge.watson.org> References: <E1GIMNJ-0000Dd-QH@cs1.cs.huji.ac.il> <2a41acea0608301145j7bbed961j33ce903a27d8963d@mail.gmail.com> <20060904130827.GE12975@registro.br> <20060911195521.GD63300@registro.br> <20060913182019.R50147@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Sep 2006, Robert Watson wrote: > On Mon, 11 Sep 2006, Marcelo Gardini do Amaral wrote: > >> I would like to discuss a little bit more about UDP performance. I've made >> some tests and the results may have some value here. >> >> In this test is easy to see that there is something different in the >> FreeBSD 6 branch. >> >> I made a benchmark with bind 9.3.2 (without threads support) and nsd 3.0.1 >> (1 server forked) on a HP Proliant Dual AMD Opteron 2.4GHz among FreeBSD >> 4.11, 6.1 and Linux kernel 2.6.15, all of them for i386 systems. I used >> this simple zone file: > > Are you able to boot a 7.x kernel on this box? An as yet un-MFC'd > optimization to the UDP send path is present in the 7.x kernel, suggested by > ISC, which significantly improves threaded BIND9 performance. I've not > benchmarked unthreaded BIND9 with the change. If you want to test > specifically the before/after case for that change, you can find the > reference to sosend_dgram in src/sys/netinet/udp_usrreq.c and swap it to > sosend, which restores the old behavior. The other common optimization advice that you may already have received is to check which time counter FreeBSD has selected. Right now, 6.x/7.x err on the side of accurate over fast. There's been quite a bit of debate about this approach, and it's useful to investigate the issue. You can view and set the current choice by looking at the sysctl kern.timecounter.hardware, and you can see the choices on your hardware by looking at kern.timecounter.choice. Typically, TSC is the fastest, but may suffer from drift as the CPU changes speed (as a result of temperature, power saving, etc). Set it to TSC if it's not already TSC, and see what the effect is. As many event libraries read time stamps frequently to set up sleeping in user space, it can have a substantial performance impact. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060913182457.W50147>