Watching performance on a DHCP Server

[David W. Hankins]

On Wed, Nov 14, 2007 at 11:01:04AM +0100, Shane Kerr wrote:
> Which version of DHCP were you using? We noticed a *massive* improvement in load
> time using 3.1 over 3.0, and a further improvement with 4.0 over 3.1.

I have a suspicion that the measurement on 4.0 was impacted by some
external event; it got more CPU because something else wasn't running
or the data was cached in memory or something.


I don't think we changed anything to improve DHCPv4 loading
performance in 4.0, except that it carries everything from 3.1.x.

There were three CPU performance improvements in 3.1.x work;

                        Changes since 3.1.0a1

- Some default hash table sizes were tweaked, some upwards, some downwards.
  3.1.0a1's tables resulted in a reduction in default server memory use.
  The new selected values provide more of a zero sum (increasing the size
  of tables likely to be populated, decreasing the size of tables unlikely).

- Lease structures appear in three separate hashes: by IP address, by UID,
  and by hardware address.  One type of table was used for all three, and
  improvements to IP address hashing were applied to all three (so UID and
  hardware addresses were treated like 4-byte integers).  There are now two
  types of tables, and the uid/hw hashes use functions more appropriate
  to their needs.

                        Changes since 3.0 (New Features)

- Some patches to improve DHCP Server startup speed from Andrew Matheson
  have been incorporated.


The last only affects loading time related to loading a dhcpd.leases
file (insertion-sorting leases from dhcpd.leases into memory was "most
pessimal").

The middle one, the hash algorithm for IPv4 addresses, only effects
IPv4 address hashing.  We're still using the old hash function for
client identifiers and hardware addresses.  The result is that the
hardware/client-id hash values may only fit in a 16 bit area, so
however big you make your hash tables, we can only use 65536 buckets,
and there is some predisposition away from a zero value, so there are
some known collisions (made worse by 'frequently similar' identifiers,
seeing as the first 3 bytes of mac addresses are often the same for
many clients).

I toyed with a few other hash functions for these other purposes
during the 3.1.x work primarily to try and exceed the 64k mark but
also to see if we could get something with fewer collisions, but
wasn't able to find one that worked well within our development
schedule, and ultimately had to queue this for later.

The first one is a another halfway mark in finishing these performance
concerns.  The main feature here is that we can now set hash table
sizes on a table-by-table basis rather than having a 'one size fits
all' philosphy (9,973 buckets for the 'DHCP Option Codes' hash
table!).  The next step is to make the sizing dynamic as entries are
added (or by counting what will be placed into it before allocation).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins