DHCP transactions per second
dhcp1 at thehobsons.co.uk
Fri Jun 15 07:10:53 UTC 2007
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
>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
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 !
More information about the dhcp-users