Watching performance on a DHCP Server

[John Hascall]

> > You may want to review the thread from the beginning. My network 
> > currently has 10,000+ DHCP clients (and I plan on accommodating double 
> > that within the lifetime of this server). I have a beefy server (4x 
> > 3.0GHz Xeon, 2x 15k RAID1) and it was only able to reliably handle 10 to 
> > 20 4-way discover handshakes a second, 2-way handshakes were maybe 
> > double or triple those numbers. When pounded by DHCP requests, it's 
> > possible that even less are processed in a timely manner due to 
> > collisions, timeouts, etc.

> I really don't understand the numbers people are quoting here. We use
> a Dell 1850 with one 3.2 GHz CPU, one Gig of memory and two SCSI disks
> in battery backed hardware RAID 1. We use this to serve 100K customers
> with 24 hour leases. No problems whatsoever, and we feel we have plenty
> of room to grow.

If a raid array is configured to signal write complete as soon as
the data is in the array's cache that can have a tremendous performance
advantage - at the cost of possibly losing the data should the raid
controller catch fire or something before the data actually makes
it to the disk.

Because we have a mobile population (lots of students with laptops)
we need to keep lease times short to prevent address starvation --
we averaged 13 DHCP handshakes per second yesterday.

Our peak is obviously quite a bit higher.  High enough, that we
are probably right on the edge of what we can do with the current
technology.  I am expecting the lease-ack-fsync buffering will
be a good thing for us (esp, if I get pressure to lower lease
times further).

John