|
The ABCs of Understanding DHCP Performance
A beginners guide to understanding operation and performance of DHCP
servers
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: June 20, 2001
Note: Birds-Eye.Net offers a DHCP Stress Testing Suite [evaluation/buy]
as well as expert consulting help for the peskiest of DHCP configurations [consulting].
Recently I was at a cable show and had run into a vendor who was talking
about their Dynamic Host Configuration Protocol (DHCP) server. This (sales)
person went on and on about how great they’re DHCP server was. He said
things like, “We’ve the fastest DHCP server in the world” and “We can
process over 70,000 DHCP transactions per second”. As a student of DHCP, I
was curious about the accuracy of this person’s claims but then again as a
former employee of a broadband operator I began to think about how this
information would be received by those looking for a DHCP server. In an
effort to educate broadband operators about DHCP, this article will provide
readers with a basic understanding of how a DHCP server works, what factors
impact performance, as well as some benchmarks that you can rely on to make
intelligent decisions regarding such a future purchase.
What is DHCP used for?
In today’s networked (Internet) world, IP addresses enable computers to
communicate with each other across distant networks. Each IP address on the
Internet represents a unique address similar to your mailing address or your
phone number. If someone wants to send you mail they must write your address
on the envelope before you can receive it and this address is unique.
Similarly, if someone wants to talk to you on the phone they have to dial
your phone number to reach you – again, each phone number is unique. The
uniqueness of your address and phone number enable anyone on earth to write
or call you. On the Internet, you must use an IP address to enable your
computer to communicate with another computer.
Your computer doesn’t come with an IP address out of the box, it merely has
the ability to host an IP address once something or someone assigns it an IP
address. Essentially there are two ways to assign IP addresses to devices
(like your computer) on a network. The first way is to manually assign it an
IP address -- this requires information from your network administrator. The
other way to assign it an IP address is to do it automatically (via DHCP).
DHCP provides a means of automating IP address distribution (assignment)
through the use of a specialized server, a communications protocol, and a
client application (see Figure 1.0).
Figure 1.0 DHCP Components
How does DHCP work?
The DHCP client is responsible for requesting an IP address from any
available DHCP server for the computer on which it resides. Today, DHCP
clients are built right into each computer’s operating system such that if
the user would like to obtain an IP address automatically, they merely have
to configure their computer to use DHCP. After that, the DHCP client does
all the heavy lifting by requesting and maintaining a valid IP address for
the computer.
The client is able to obtain an IP address through the DHCP protocol. This
protocol governs the communication between the DHCP client and the DHCP
server that oversees the IP address distribution. The DHCP communications
defined in this protocol (see Figure 2.0) consist of two handshakes between
the DHCP client and the DHCP server. The first handshake involves an attempt
by the DHCP client to find an available DHCP server. The initial message
(called a DHCP Discover) is sent out by the DHCP client and contains
identification information about the client as well as what if any it
requires. Any DHCP server that receives this message makes a decision on
whether to respond. If a response is warranted, the DHCP server creates a
temporary IP address assignment and then sends a response message (called a
DHCP offer) back to the client. The offer contains the IP address that is to
be supplied to the client along with other information the client requested.
This process completes the first handshake.
Figure 2.0 DHCP Communications
Unfortunately, there could be a number of DHCP servers all running on the
same network. This combined with the fact that the DHCP protocol is one way
a second handshake is needed to verify the first handshake. During this
second handshaking, the DHCP client selects an offer and then sends a second
message (called a DHCP request) to any and all available DHCP servers
acknowledging the particular offer it has selected. The selected DHCP server
then sends a response message (called a DHCP Ack) to the client to
acknowledge its selection and then it commits its temporary IP address
assignment for that client to its database. Any other DHCP server(s) not
selected do not reply to the DHCP client but instead release their temporary
assignment made to this client in response to it selecting some other DHCP
server.
The DHCP server controls the process of automated IP address distribution
that pertains to DHCP specifications. Since DHCP is a standard, its
responses to requests must adhere to the specifications that have been
adopted by the industry. These specifications, also called requests for
comment (RFC)s, explicitly state how DHCP servers must interact with DHCP
clients on a network. While the manner in which the DHCP server responds to
requests and what is contained within the requests and responses are
dictated by the RFCs, how each DHCP server actually conducts this is left
completely up to the vendor and how they choose to implement or develop
their DHCP server. As a result, all DHCP servers are not created equally.
The rest of this article will focus on how DHCP servers approach this
problem of complying with standards yet differentiating themselves from
other competing products.
What is in a DHCP server?
A typical DHCP server contains the components shown in Figure 3.0. These
components include (briefly) the engine that is responsible for processing
incoming DHCP messages and then sending out appropriate response messages
when necessary. The cache provides a means of more quickly interacting with
the DHCP server’s database – this component is optional. The database houses
all the data required by the DHCP server to run. The server log contains a
list of all the diagnostic activity going on in the DHCP server. Memory
contains all the information that the server needs from the database and is
loaded when the application starts. Lastly, the transaction log is a list of
all the server/client transactions that have not yet been committed to the
database – this component is also optional.
Figure 3.0 DHCP Server Components
While this brief description of DHCP server components is by no means
comprehensive in terms of how each vendor has went about building their DHCP
server, it does represent the major components most commonly used.
Understanding these basic components provides a foundation on which to
understand performance.
Understanding Performance
The diagram shown in Figure 4.0 summarizes the relationships between the
DHCP operational areas listed that all play an inter-dependent role in its
performance. In this diagram Startup time refers to the time it takes for a
DHCP server to start up. A DHCP server that can start up quickly does not
have a lot of homework to do (such as committing entries in the transaction
log to its database or loading lots of information into memory) before it
begins processing requests. A quick startup time is highly desirable as if
one needs to make changes to the server or cycle it for any reason the
server could quickly become operational with little (if any) impact to the
DHCP clients it maintains. Persistence refers to the ability of a DHCP
server to keep state. Persistence also refers to a DHCP server’s ability to
recover from a disaster – like unplugging a running server. In large
networks persistence is critical as the loss of any transaction may hang the
DHCP clients whos transactions are left in limbo (not committed to the DHCP
database). The last area is processing speed that refers to a DHCP server’s
ability to quickly receive, process, and answer requests.
Figure 4.0 DHCP Performance Dependencies
Per the diagram in Figure 4.0 one cannot supply superior performance in any
one area without impacting the other areas listed. For example, if one
maximizes performance in processing speed it must in turn sacrifice its
ability to startup quickly and will not be able to guarantee that if it was
suddenly interrupted (e.g. shut off) that it would loose some transactions.
Ideally, a DHCP server should handle all these areas equally well – and most
do. In fact, the high-end DHCP servers generally expose operational
parameters that allow you to move around in the triangle above and emphasize
more of one area. However, with all things being equal (similar machines and
operational settings) a majority of the vendors fall into the middle of the
triangle and do not exploit any one area. But if all attempt to do basically
the same thing, why the parity in stated performance numbers? I believe, the
listed performance numbers are all best case. In other words, you would not
get these numbers in a real operational scenario because you would not run
your server in configuration that was optimized for processing speed.
However, the more DHCP venders seek out the middle ground the less unique
they are. So, claiming a fast transaction speed as a sales person alluded to
previously may be the only way various DHCP servers can claim superiority.
What are some of the techniques vendors use then to optimize performance?
Some vendors load everything into memory! If everything is memory that
server can likely beat any other server in a race for processing speed.
However, what vendors fail to explain is how well their servers keep what is
stored in memory in sync with what is in the database. Note if nothing hits
disk (i.e. the disk drive which is where the database resides) a power
failure will be disastrous for these fast servers. These vendors also fail
to mention how long these servers take to start up or handle changes.
Consider reading ones entire database and loading that in memory or adding a
new network and how long that should take before you believe any performance
numbers.
Put a Stop to the Madness
Having lived in the trenches of running a big time DHCP server I can tell
you horror stories of what I’ve been promised and what I’ve seen. Since
there are no standard benchmarks for DHCP servers you can basically throw
out any performance claims. Essentially, these claims state that if you set
up their server in a “lab” and throw lots and lots of well-formed DHCP
packets at the server it will process this many packets per second. Well
there is an eternity of distance between testing in a lab and running a
server on a big time network. Only a hand full of DHCP server vendors today
can claim their server maintains a network of more than a 100,000 DHCP
clients. Even these big time DHCP server vendors haven’t seen everything –
new cases of bad packets are always popping up. Its like there is a lot of
bad DHCP client code out there and they all do something the DHCP server is
not prepared for. Handling these problems in many cases require changes to
the DHCP server application.
Memory vs. Disk
If one commits everything to only memory the performance of the DHCP server
is only limited by the hardware and network connecting to the server –
assuming the server is equipped to handle the load. However, if you want
anything to hit disk (which you better) your ultimately limited by the
physical properties of disk drives (seek times and throughput). One of the
most efficient transaction with a disk drive is an append file (adding on to
the end of an existing file). This is because the disk head does not have to
move before you write any data. DHCP vendors that focus on performance
exploit ways to optimize their use of disk drives to store data so as to not
slow their applications down (while they wait to write data). There are
likely many different tricks to increase the speed here as well (such as
increasing the number of disks and or memory) but to append some basic
information to a file takes around 0.00041 seconds. To put this another way,
if all your DHCP server had to do was append a file to store data (typical
DHCP servers actually do more than this) in its database it could process
around 2,439 transactions per second. A far cry from 70,000 but that is the
most a DHCP server could achieve if it must write each transaction to disk.
Summary:
There are many different ways one can configure a DHCP server
that allow it to meet the operational demands of your broadband network.
Optimizing performance of a DHCP server typically does not go hand in hand
with configuring it to meet your operational requirements. Although broad
claims are made about DHCP server performance in an effort to differentiate
one server from another, operational requirements will ultimately dictate
actual performance – which will be significantly lower than initial claims.
Check out these other Birds-Eye.Net papers/products regarding DHCP:
Products:
White Papers and Reading Material
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|