When you think of optimizing a server's performance, you probably don't immediately think of your DHCP Server. Performance optimization has always been traditionally focused around things like database servers, file servers, and mail servers. DHCP servers just chug along happily in the background. Although it might not be as critically important for a DHCP server to have absolute optimal performance as it might be for other types of servers, it does make sense to at least take a look at how your DHCP servers are performing. After all, a performance problem on a DHCP server could lead to some PCs being unable to lease an IP address at boot up. Although such a condition would likely be temporary in nature, it would impact your user's productivity and would cause the help desk to receive additional calls.
Many of the performance optimization techniques that you would use for optimizing a DHCP server are similar to the techniques that you would use to optimize a file server. There are however some Performance Monitor counters that are designed specifically with DHCP servers in mind. By examining a combination of DHCP specific and generic Performance Monitor counters, you can get a good idea of how your DHCP server is performing.
An introduction to the Performance Monitor
As you may or may not already know, the utility used to monitor a server's performance is the Performance Monitor. For the benefit of those who might not be familiar with performance monitoring, I'm going to give a quick crash course in how to use the Performance Monitor. If you are already familiar with the Performance Monitor, then feel free to skip ahead to the next section.
The Performance Monitor is accessible by selecting the Performance command from your server's Administrative Tools menu. When the Performance Monitor opens, you will see a screen that looks something like the one that's shown in Figure A.
|This is the default Performance Monitor screen.|
As you can see in the figure, the Performance Monitor's primary feature is a graph. The various colored lines on the graph correspond to the counters listed at the bottom of the screen. For example, in the figure, the blue line corresponds to the Pages/sec counter. A counter is simply a mechanism for monitoring some specific aspect of system performance.
The Performance Monitor contains hundreds, if not thousands of counters that you can monitor. To make it easier to locate a specific counter, counters are grouped by performance object. A performance object is nothing more than Microsoft-speak for a category. For example, counters related to memory are found within the Memory performance object.
Now that you know the basic terminology associated with performance monitoring, it's time to prepare the Performance Monitor for use. You will need to remove the default counters in an effort to declutter the screen and make it easier to read the counters that you are really interested in. The act of monitoring counters consumes some system resources itself. Therefore, the more counters that you monitor simultaneously, the more resources are being consumed by the monitoring process, and the more skewed the results will be. It is best to monitor counters one at a time unless you need to cross reference the value of various counters.
To remove a counter, simply select the counter from the bottom of the screen and then click the icon that looks like a capital X at the top of the console.
After the default counters have been removed, you can add counters to the Performance Monitor by clicking on the icon that looks like a plus sign. Upon doing so, you will see the Add Counters dialog box shown in Figure B.
|The Add Counters dialog box allows you to add Performance Monitor counters to the graph.|
To add a counter, simply select the appropriate performance object from the Performance Object drop down list. Upon doing so, the Counters list will display the counters that are related to that performance object. In some cases, you may also have to select an instance. An instance is used when the system contains more than one thing that can be measured by the counter. For example, if a system contains multiple processors, then there would be multiple instances available for each processor related counter.
Throughout this article, I will be discussing a number of different counters that you can monitor. As I do, I will list the counters in object\counter format. For example, the % Processor Time counter is contained within the Processor performance object. Therefore, this particular counter would be listed as Processor\% Processor Time.
As I mentioned earlier, there are a number of Performance Monitor counters that are related specifically to the DHCP services. You can use these counters not only to see how well your DHCP server is performing, but also the number of requests being received by the DHCP server at a given time.
When a client is initially brought online, it has no IP address and no knowledge of DHCP servers on your network. Consequently, it will transmit a DHCPDISCOVER packet in an effort to detect DHCP servers on your network.
One way that you can measure the load that is being placed on your DHCP server is to look at how frequently it receives a DHCPDISCOVER packet. You can do so by analyzing the DHCP Server\Discovers/sec counter. This counter will display the number of DHCPDISCOVER packets detected each second.
When a DHCP server receives a DHCPDISCOVER message, it replies with a DHCPOFFER packet. This is the server's way of informing the client of its existence. The DHCPOFFER packet contains information such as the length of time that the server is willing to lease an address for, the client's subnet mask, a broadcast address, a list of routers on the subnet (sorted by order of preference), a domain name that should be used when resolving host names, and the IP address of the DNS server.
Because DHCPOFFER packets are transmitted in response to DHCPDISCOVER packets, the number of DHCPOFFER packets sent each second should roughly mirror the number of DHCPDISCOVER packets sent each second. Some variance is normal though because of server latency. You can use the DHCP Server\Offers/sec counter to determine how many DHCPOFFER packets are being sent each second. If the number of DHCPOFFER packets seems low compared to the number of DHCPDISCOVER packets, then the server may have a performance bottleneck that needs to be addressed.
When a client initiates a DHCPDISCOVER, It is possible that the client may receive multiple DHCPOFFER messages (assuming that there are multiple DHCP servers on the network). For this reason, the client must choose which DHCP server it wishes to lease an IP address from. The client does this by transmitting a DHCPREQUEST packet to the desired DHCP server.
You can monitor the number of DHCPREQUEST packets that a DHCP server receives each second by monitoring the DHCP Server\Requests/sec counter. Keep in mind that if your network contains multiple DHCP servers (or a router or wireless access point with built in DHCP capabilities) then the number of DHCPREQUEST packets received will not correspond to the number of DHCPDISCOVER packets received or the number of DHCPOFFER packets sent.
When a DHCP server receives a DHCPREQUEST packet, the server replies with a DHCPACK packet. This is an acknowledgement packet that the DHCP server sends to the client to confirm that the client can lease the IP address that was previously offered.
You can monitor the number of DHCPACK packets that are transmitted each second by using the DHCP Server\Acks/sec counter.
It might at first seem that the number of DHCPACK packets transmitted each second should roughly mirror the number of inbound DHCPREQUEST packets. Ideally, this would be the case, but it doesn't always work this way.
If a client had previously leased an IP address from a DHCP server, then the DHCPREQUEST packet sent by the client will contain a request to reuse the previously issued IP address. The problem is that the requested IP address might have been issued to someone else during the time when the client that is requesting the address was offline.
If a DHCP server receives a DHCPREQUEST packet requesting an IP address that is not available, then the server will return a DHCPNACK packet, which is the server's way of telling the client that the request was denied. You can monitor the number of DHCPNACK packets transmitted by the server each second by looking at the DHCP Server\Nacks/sec counter.
You might've noticed that none of the counters that I've talked about so far will give you an accurate representation of how many inbound packets the DHCP server is actually received. If you want to measure the overall request placed on your DHCP server, then I recommend checking out the
DHCP Server\Packets Received/sec counter. This counter will display the total number of inbound DHCP packets each second.
Active Queue Length
If you are trying to measure how well your DHCP server is keeping pace with the demands being made against it, then a great counter to monitor is the DHCP Server\Active Queue Length counter.
The basic idea is that when requests are received by a Windows based DHCP server, those requests are not immediately process, but are rather placed into a queue for processing. Normally, this queue should contain no more than a couple of items that most. However, if the server is experiencing a heavy workload and is having trouble keeping pace with the demand, then the queue can become backed up. By watching the active queue length, you can gauge just how efficiently your server processes requests.
A counter related to the active queue is the DHCP Server\Packets Expired/sec counter. If a packet sits in the active queue for 30 seconds, then the packet is considered to be stale, and is automatically expired. A high number of expired packets usually indicates a serious performance problem with the server.
Another queue that you can monitor is the conflict check queue. As I'm sure you know, each host on a network must have a unique IP address. Because IP address conflicts can cause problems, Windows based DHCP servers have the ability to test for the presence of an IP address prior to issuing it. Basically, this means pinging the address that is about to be assigned to make sure that nobody else is already using the address.
When conflict detection is enabled, addresses that are about to be assigned are placed into a queue. From there they are checked in turn for conflicts. Like the active queue, the conflict check queue's length should contain no more than a few items at any given time. Excessive queue lengths can indicate a performance problem or that the number of conflict detection attempts has been set too high on the server. You can monitor the conflict check queue length by looking at the DHCP Server\Conflict Check Queue Length counter.
Just because a client requests an IP address and a DHCP server returns a DHCPACK message, it does not mean that the client always accepts the address. If the client detects that another host on the network is already using the address, then it will return a DHCPDECLINE message to the server, indicating that it does not want the address.
Normally, DHCP declines should not happen. The presence of DHCPDECLINE messages almost always represents a network configuration problem. When this occurs, the first thing that you should do is to enable conflict detection. You can test for the presence of DHCPDECLINE messages by looking at the DHCP Server\Declines/sec counter.
Another counter that you can monitor is the DHCP Server\Releases/sec counter. This counter displays the number of times per second that DHCP issued IP addresses are released by a client. Normally, addresses are only released if the client is configured to release leased addresses on shutdown, or if the client manually releases an address by issuing the IPCONFIG /RELEASE command. As such, this probably isn't the best counter to monitor in an effort to gauge your server's performance, but I wanted to at least mention it.
A better counter to monitor when server performance is of interest to you is the DHCP Server\Duplicates Dropped/sec counter. The idea is that sometimes duplicate packets are sent to a DHCP server, which in turn drops the duplicates. Duplicate packets can be caused by having multiple DHCP relay agents that forward the same packet to the server. However, dropped duplicates can also indicate that clients are timing out too quickly, or that the DHCP server is not responding quickly enough.
A counter that may or may not be of interest to you is the DHCP Server\Informs/sec counter. This counter indicates the number of times per second that DHCPINFORM messages are received by the server. These messages occur when the DHCP server queries the Active Directory for the enterprise root or when the server performs dynamic updates on behalf of the clients.
Milliseconds per Packet
The DHCP Server\Milliseconds per packet (Avg.) counter indicates the number of milliseconds that the DHCP server takes to process each packet that it receives. Unfortunately, I cannot tell you what an acceptable value for this counter is because the value varies widely from server to server depending on the server's hardware and workload. What I can tell you is that it is a good idea to monitor this counter in an effort to determine what is normal for your DHCP server. If this value should suddenly increase, then there is a good chance that the server's workload has increased, and that some system component is becoming a bottleneck.
Counting the counters
As you can see, there are a number of DHCP specific Performance Monitor counters that you can use to determine how well your DHCP server is handling the current workload. I recommend using these packets to determine whether or not a performance problem exists. If you do detect a performance problem, then your best course of action is to use more traditional performance monitoring techniques (such as monitoring of the CPU, hard disk, and memory) to determine where the problem lies.