DHCP transactions per second

[Simon Hobson]

Ian Anderson wrote:
>I am trying to do some stress testing on our dhcp servers (3.1.0b2) and 
>am looking for anyone else who has had to do this, to offer up there
>thoughts.

David W. Hankins posted a message a while back with some stats he did 
- try searching the archives.

>   I am currently trying to figure out what our current servers
>tps count is.
>
>If I have 40,000 clients, those clients at any given time could be doing
>4-way transactions (DHCPDISCOVER/OFFER/REQUEST/ACK) or 2-way (RENEW/ACK).
>
>With 40,000 clients each doing 4 transactions in 24 hours(DHCPDISCOVER),
>this computes to 160,000 transactions in 24 hours. If I divide that by
>86400 seconds this comes out to ~1.85 4-way transactions per second.
>
>However if the client is doing DHCPRENEW's this is a 2-way communication
>which lowers the transaction count.  Our lease times are set to 86400
>(24 hours)  So every 43200 seconds (12 hours) clients are going to do a
>DHCPRENEW/ACK. Using the same formula as above 40000 * 2 = 80000
>transactions in 12 hours. 80000 * 2 = 160000 2way transactions in 24
>hours. 160000/86400 = ~1.85 2-way transactions per second.
>
>Both DHCPDISCOVER and DHCPREQUEST values compute to the same tps. Could
>one conclude that when attempting to compute dhcp tps, you only need to
>take DHCPDISCOVER 4 way handshakes into account?

In effect the 4way handshake is two separate transactions. Also, 
clients renew BFORE their leases expire - typically at half the lease 
time. So that also doubles the transaction rate. Add to that clients 
that renew because they've just been started/had a network cable 
plugged in/whatever.

>Math was never my strongest subject and I am hoping someone can offer
>advise as to wether or not this is the proper way to compute DHCP tps.

It's far more complicated than that ! IFF your clients renew in a 
truly random fashion then your thinking is correct, but they don't.

Firstly, as mentioned above, they will renew at half the lease time. 
If that doesn't succeed (server down ?) then they will keep trying 
with increasing frequency until they either renew or the lease 
expires.

Also, clients will renew : when they are booted, when they connect to 
a network (part of the booting process but can happen at other 
times), when they wake/resume (for clients with a sleep/hibernate 
function).

Many clients also do DHCP-Inform transactions.


Then you have to consider the nature of your client base. Are they on 
and connected 24x7 ? Or do they start up in the morning and shut down 
at night (5 days/week) ? If it's the latter then you can expect a 
burst of renewals every weekday morning when staff come in to work, 
and you can expect a similar burst of discover/request transactions 
every Monday morning as all the clients leases will have expired over 
the weekend.

How geographically spread are your clients ? Are they in an area 
prone to power cuts ? Do they automatically start up when power is 
applied or do they sit there waiting for a user to start them up ? 
The worst case would be if they were broadband routers etc and you 
had a widespread power cut - when power came back, you would get a 
large number of near simultaneous requests (spread mainly by any 
sequenced power up done by the electric company and differences in 
startup times of different router models) ! With routers you also 
have the small detail that most of them don't have any read/write 
memory and so don't have a persistent lease store - after a power off 
they will always have to start with a DHCP-Discover.



Now, to things you can do to help.

Firstly, increase your lease times unless there's a reason not to. At 
my last job I used several weeks, but with a small pool for visitors 
with an 8 hour lease. That minimises the leases that will ever expire 
(so you almost eliminate the DHCP-Discover/Offer part of the load). 
Clients will only renew every couple of weeks, or more likely at 
bootup (or one of the other events mentioned above) which minimises 
the renewal rate.

Turn off synchronous logging in syslog. Each DHCP event may create 
several log entries (especially if there's a DDNS entry) and if you 
have synchronous logging then each log entry results in a disk write.

That brings to mind another detail. With 24 hours leases and a 
'working week' pattern of usage then you will have lots of leases 
expire over a weekend. If you DDNS then that means a lot of DNS 
updates when the clients get new leases on Monday morning. These put 
a significantly higher load on your system(s) that simple renewals 
and should be avoided if you are struggling for performance.

Lastly, just accept that 's**t happens' - sooner or later you may 
have an event that results in a higher than normal load (perhaps the 
power is off across the country for a couple of days, rare but it can 
happen). Don't try and 'plan' for it, just be aware what it will do 
and accept that you will have a high load for a bit and it may take 
clients a while before they can get back up and running. For example, 
if the clients are broadband routers then they may time out and give 
up requiring the user to restart them - so be prepared for a surge in 
calls to the helpdesk !