DHCP transactions per second

[Ian Anderson]

Simon Hobson wrote:
> 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.
>   
We are a mobile ISP. That being said the vast majority of our customers 
are not carrying their computer around with them.  Most of our customers 
are in a static locations.  Since I am dealing with customers, I have no 
idea how often they power cycle their CPE, or shutdown their computer, 
etc.  This is what makes calculating DHCP tps extremely difficult.
> 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.
>
>   
Good point on the routers, I didn't think about that. The majority of 
the customers being served from this particular dhcp server are in the 
pacific northwest.  WA, OR, ID, etc. 
>
> 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.
>   
What do you mean synchornous logging?  Do you mean disable logging all 
together? 

> 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.
>   
No DDNS updates.
> 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 !
>
>