Share via

DHCP Server Performance in Windows Server 2008 R2

  • Article

 

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_MACHINESYSTEMCurrentControlSetservicesDHCPServerParameters. 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)

2,000,000

1500

7400

875

660

 

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.

Test Scenario

Windows Server 2008 R2

Windows Server 2008

Address Acquisition

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

25

Expand a scope

2

Database Backup

13

Export

135

Dump

45

 

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)

Comments

  • Anonymous
    January 01, 2003
    Thanks Ami for sharing your report on the DHCP server performance in Windows Server 2008 R2. Prasad Team DHCP

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    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. Prasad

  • Anonymous
    January 01, 2003
    Hi,  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. Thanks Sam

  • Anonymous
    January 13, 2010
    The comment has been removed

  • Anonymous
    August 06, 2010
    well... i did somthing similar, worth reading peramida.com/.../239 your comments are more than welcome

  • Anonymous
    November 22, 2015
    I'm curious what the IP subnet/pool was for your test? A single prefix/pool with all 2 million addresses i.e. a /19, or was it multiple smaller prefixes/pools?