DHCP transactions per second
ian.anderson at clearwire.com
Fri Jun 15 17:22:55 UTC 2007
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
> 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
> 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
> 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
> 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 !
More information about the dhcp-users