With the proliferation of IP devices on the enterprise network, network services like DHCP are expected to deliver on ever increasing load while maintaining low response times. DHCP Server in Windows Server 2008 R2 has been enhanced and tested to deliver far higher levels of performance and scalability than in previous releases of Windows. The cornerstone of the performance improvement in the DHCP server in the latest release has been aggressive caching of the lease records in database.
A bit of context to let you see how the cookie crumbles: DHCP server uses Jet database engine also referred as Extensible Storage Engine (ESE). ESE provides a facility where the whole or part of the database can be cached in memory to improve lookup performance and to reduce dependence on expensive file IO which can drain performance. In Windows Server 2008 R2, DHCP Server sets the Jet db cache to “autotune” mode which allows Jet db to aggressively cache the DHCP database in main memory. The cache is built up as and when the database records (in the case of DHCP, lease records) are accessed (renew existing lease) or created (assign a new lease). So, you are likely to see a growth in the DHCP server process size over a period of time as the existing records in the db are accessed or new records are created.
A new DHCP registry parameter of type DWORD can be added to exercise greater control over the size of the database cache: the value JetDatabaseMaxCacheSize can be added under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DHCPServer\Parameters. The value entered is taken as the maximum size (in MB) of the cache that DHCP server can use. If the value is set to greater than the physical memory in the system, the cache is automatically capped at the size of physical memory in the system. If set to a value lesser than 2 MB, the cache is set to 2 MB – in other words, cache cannot be set to a value lower than 2 MB (floor value). It is recommended not to set any value here and let the DHCP server allocate memory for cache as needed unless there are other services/roles running on the same computer. If there are other services/roles running on the same computer as the DHCP Server, you may want to set a cap on the DHCP server cache so that other services/roles are not starved of memory.
Now onto some test results: we fired up our scalability and performance tests to see how far this change would take us in terms of performance and scalability. The objective of the scalability test was to ascertain the throughput that the DHCP server was able to deliver on a) New leases being granted per second b) Renewal of existing leases per second. The test runs to determine new leases per second and renewal of existing leases per second were conducted separately (i.e. there was no renew traffic to the server in the test for new leases per second and vice-versa).
The hardware configuration used for conducting the tests was as follows:
· Model: HP ProLiant DL385 G1 (HP server for small-medium business)
· Processor: 2 Dual Core AMD Opteron 64 bit 2.2 GHz
· RAM: 6 GB
· Storage: 136 GB SCSI hard disk.
Here the test results:
Active IP address leases in the DHCP db
New IP leases granted per second
Renew of leases per second
Size of database on disk (in MB)
DHCP Server process size (in MB)
As can be seen from the results above, the DHCP server on afore mentioned hardware was able to assign, on an average, 1500 IPv4 leases per second. This was on a database which had 2 million active IPv4 lease records. On the same test setup, the DHCP server was able to renew leases at the rate of 7400 renews per second on an average. These results are indicative of the ability of the Windows DHCP server to deliver higher performance in terms of new IP address leases per second and IP address renews per second with a very high number of active IP address leases already in the database. The DHCP server database size on disk for 2 million leases was around 875 MB and the process size was around 660 MB.
In a pure performance test (low number of active leases in the database), the DHCP Server clocked 3200 IPv4 leases per second showing a 4 fold increase in performance over Windows Server 2008.
Windows Server 2008 R2
Windows Server 2008
3421 leases per second
853 leases per second
Address Acquisition and Address renew operations (in ratio of 60:40)
4400 transactions* per second
676 transactions* per second
* A transaction is either a new address (lease) acquisition or a renew of an exisiting address.
A similar test for IPv6 had the server clock close to 2800 leases per second – a staggering 50X improvement over Windows Server 2008.
When it comes to scalability, people often get too focused on the scalability figures for number of active leases which the server can handle. It is equally important from a real world deployment point of view to ensure that the management and maintenance operations of the server keep up at the high scale. In line with that thought, we did a series of tests to test the scalability of MMC, export/import and backup/restore operations. With over 1 million IPv4 leases spread over 6000 IPv4 scopes, using DHCP MMC, it took about 25 seconds to expand the IPv4 node while any scope expansion was complete in 1-2 seconds. Time taken for backup of the database was about 13 seconds while export took 2 mins 15 seconds. Dump of the database took 45 seconds to complete.
Operation (on a database with 1 million IPv4 leases)
Time Taken (in seconds)
Expand IPv4 node
Expand a scope
A similar test for over 1 million IPv6 leases spread over 6000 IPv6 scopes, yielded 2 minutes for IPv6 node expansion and 2 minutes for any scope expansion in MMC. Backup of the database took about 20 seconds while export of the database took about 1.5 min. Dump of the database took 48 seconds.
Operation (on a database with 1 million IPv6 leases)
Expand IPv6 node
As you can see from these results, the management and maintenance operations of the server maintain their responsiveness with high number of active leases in the database. These results hold good for all the Windows Server 2008 R2 SKUs.
Though in a lab environment, the above results stand testimony to the high scale and performance that Windows DHCP server can deliver in enterprise as well as in carrier grade deployments.
We did like to hear from you if this test data was useful and what other performance or scalability metrics you would like to know about.
We have had questions asked of us on the impact of the new link layer filtering (aka MAC address based filtering)on the DHCP server performance.
Based on the testing conducted for measuring impact of MAC address based filtering on performance, we have found negligible performance drop with MAC address based filtering configured.
With 100,000 MAC addresses configured (50,000 each in allow and deny list), the drop in average response time was to the order of 1-2% across multiple test runs.
Any chance of detailing how (configuration) the tests were conducted?
We are looking at upgrading and potentially consolidating a DHCP solution for a large telco which currently has DHCP servers geographically spread, are their "best practices" for a distributed (huge distances!) spread DHCP solution from Microsoft?
Any guidance would be greatly appreciated.
it is not a comment but questions regarding DHCP
what the best practice to implement dhcp
- hardare device or windows server
how to implemente the high available DHCP SOLUTION
For high availability of Windows DHCP server, you can either go for a cluster based approach:
see http://technet.microsoft.com/en-us/library/ee405263(WS.10).aspx for a step-by-step guide
or use a split scope configuration see: http://technet.microsoft.com/en-us/library/ee405264(WS.10).aspx for a a step-by-step guide.
well... i did somthing similar, worth reading
your comments are more than welcome
Thanks Ami for sharing your report on the DHCP server performance in Windows Server 2008 R2.