bench marking

kalyanasundaram s.kalyanasundaram at
Wed Dec 20 05:26:47 UTC 2006

  Does anyone has done dhcp benchmarking already. What are the
measurement variables you have considered? How did u measure those
parameters. I will be happy if somebody has done something earlier.

some time back David has started some thread, i would like to continue
on that.

>Naturally the first thing I thought of was disk performance: how
>many fsync()s per second, and the usual advice about prepending
>a "-" to your log file names in /etc/syslog.conf on the Linuxes,
>reducing drive activity, etc.  The idea being not to use a
>regular local disk, but rather a more capable write-back array
>or even a solid-state disk on a battery.

 What are the other parameters generally considered for dhcp benchmarking other than the disk?.

>I happened to have a dual opteron system with 4GB of RAM and
>a nice (old) 10-spindle raid array whose PCI controller uses a
>battery backed-up cache (so it is write-back).

I hope i dont have anything do to with RAID.

>Some datapoints, then.  First, fsyncs per second (after writing
>a fairly average sized lease structure first, every entry in one
>of the lease databases one of you users has donated to me over
>the years):

>  Laptop Hard Drive:					40
>  Mylex ExtremeRAID (DAC960 derivative) w/battery:	400
>  RAMdisk:						34,966

>That doesn't sync up with the "4-7 leases per second" benchmark
>we hear off and on when someone visits us to report that ISC
>DHCP severely underpforms Windows' (which does not sync its
>lease db before answering clients).

So the fsync is done automatically? or we need to configure something to make it for every second?. 

>So I created a very synthetic benchmark: I altered the DHCP IO
>subsystem to pass down a manufactured DHCP DISCOVER and REQUEST
>packet that I had foreknowledge the server would answer a
>specific way.  Infinite looped it, then counted replies.  The
>result is an infinite DISCOVER/OFFER/REQUEST/ACK, and all of
>the server's code is excercised (minus the read() to pull the
>packet off the socket - one less system call).

>This was easier at that moment than constructing a daemon to
>spam dhcp client requests.

Pretty interesting.. I was looking for this one. What is the DHCP IO Subsystem? 

>I went straight for the high performance subsystems.  (Plus, this benchmark
>isn't very usable on the laptop (packet flooding the broadcast
>  Mylex ExtremeRAID:	160 packets per second (in+out)
>  RAMdisk:		10,000 packets per second (in+out)

>That's packets per second, so you'd have to halve the numbers
>to get queries/responses numbers, then halve again to get
>offer vs. ack (1 out of every 4 packets is one of these).

>So that's 40 offers and 40 acks, 2,500 offers and 2,500 acks
>respectively, per second.

These are scaled values for dchp? I mean expected values in high performing systems.

>Removing the DISCOVERs and going straight for the REQUEST's (I
>knew this lease was active in the db, so I knew it would work):
>  Mylex ExtremeRAID:	85 packets per second (in+out)
>  RAMdisk:		8,500 packets per second (in+out)
>That's curious.  I expected ~80 on the RAID array.  Fsync() is
>the limiting factor after all, and we do that only on the
>requests, so I'd expect to get half the previous number.  But
>8,500 is not half of 10,000...that's odd.

>Going back to compare fsync()s/s with requests/s:
>  Laptop hard drive:	40	4-7?
>  Mylex ExtremeRAID:	400	40-42
>  RAMdisk A:		34,966	2,500 (discover/offer/request/ack)
>  RAMdisk B:		34,966	4,250 (request/ack)
>So actual performance is (very) approximately 10% of the fsync()
>rate, until you get into the very high number of leases per
>second, at which point it is coupled at an even higher 12.2%.
>If you are only serving clients in INIT state (or assuming some
>worst case), it's lower at 7.2%.  I'm guessing CPU starvation
>is the cause, but I haven't had the time to repeat the test and

>I wouldn't have expected there to be a curve there (or if there
>was a curve, I expected it to go only down, as other non-fsync
>related limitations took over as the new bottlenecks and faster
>fsyncs mattered less and less).

>But both of those are still smaller numbers than I'd previously

if anybody has done something related on this please let me know. 

Thanks for your all help,

More information about the dhcp-users mailing list