dhcp1 at thehobsons.co.uk
Wed Dec 20 07:54:10 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
Apart from the thread you've already seen, I don't think there has
been any benchmarking - there's just too many variables.
> >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.
If I read that as it's written then I hope you never administer any
important system then ! Raid isn't hard to do, especially with a
hardware controller, and it's really really important to a good
reliable (and high performance) server. I've been kept out the s**t a
few times by raid controllers when a disk has died.
> >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
>> 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?.
Yes that's automatic - it writes the lease and then calls fsync to
ensure it's written to disk. Only after this can it reply to the
client, it's required by the rfc. As stated, this is one (just one)
of the things Windows server is non-compliant about.
> >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
The bit of the source code that handles IO
> >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
It should be possible, BUT just think what those numbers mean. If you
have a conservative 8 hours lease, 40 clients/second equates to over
half a million clients. In practice you'd need to have somewhat less
to allow for the inevitable bunching of requests at certain times of
the day. Make the leases longer and the numbers get better - don't
forget that for renewals, there are half the packets (just a
request-ack instead of discover-offer-request-ack).
Certainly we've had reports of people supporting many tens of
thousands of clients with one modest box.
>if anybody has done something related on this please let me know.
I don't think so. Unless you have a really HUGE client base, then
performance is something you simply don't have to think about on a
typical server. Serving a few hundred or few thousand clients is
something you can simply throw on whatever server you happen to have
running and you'll simply not notice the load.
More information about the dhcp-users