DHCP performance considerations

It is important to understand that certain configuration keywords and the structure of the configuration file have an effect on the memory use and performance of the DHCP server.

First, excessive memory use can be avoided by understanding the inheritance model of options from parent to child containers. In an environment that supports no unlisted clients, the administrator must explicitly list each client in the file. When options are listed for any specific client, the server uses more memory storing that configuration tree than when options are inherited from a parent container (for example, the subnet, network, or global containers). Therefore, the administrator should verify whether any options are repeated at the client level within the configuration file and determine whether these options can be specified in the parent container and shared by the set of clients as a whole.

Also, when using the logItem entries INFO and TRACE, numerous messages are logged during the processing of every DHCP client message. Appending a line to the log file can be an expensive operation; therefore, limiting the amount of logging improves the performance of the DHCP server. When an error with the DHCP server is suspected, logging can be dynamically re-enabled using either the SRC traceson or dadmin commands.

Finally, selecting a numprocessors value depends on the size of the DHCP-supported network, the pingTime db_file configuration parameter, and the typical propagation delay on the network. Because each packet processor thread issues an ICMP Echo Request to verify the status of a server-owned address before offering it to a client, the amount of time that any Echo Response is waited for directly affects the amount of processing time for a DISCOVER message. Essentially, the packet processor thread is able to do nothing more than wait for any response or for the pingTime timeout. Lowering the numprocessors value improves the response time of the server by lowering the number of client retransmissions, yet still maintaining the ping benefit of the server design.

For best performance, select a pingTime based on the propagation delay of any remote networks supported by the DHCP server. Also, select the numprocessors value based on this pingTime value and the size of the network. Selecting a value that is too small can cause all packet processing threads to be stopped. The server is then caused to wait for any Echo Responses while incoming DHCP client messages are queueing on the server port. This causes the server to handle client messages in batches rather than in a constant stream.

A selected value that is too small can cause all packet processing threads to be stopped waiting for any Echo Responses.

To prevent this situation, set the value for numprocessors to a number higher than the estimated number of DISCOVER messages that can be received within one pingTime interval during a period of high DHCP client activity. However, do not set the numprocessors value so high that it could burden the kernel with thread management.

For example, the values numprocessors 5 and pingTime 300 cause poor performance in an environment with a potential 10 DISCOVER messages per second because at peak demand, only 5 messages are handled every 3 seconds. Configure this environment with values similar to numprocessors 20 and pingTime 80.