<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
-------- Original Message --------<br>
Subject: Re: Watching performance on a DHCP Server<br>
From: Olaf van der Spek <a class="moz-txt-link-rfc2396E" href="mailto:olafvdspek@gmail.com"><olafvdspek@gmail.com></a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@isc.org">dhcp-users@isc.org</a><br>
Date: Monday, February 11, 2008 3:55:24 PM<br>
<blockquote
cite="mid:b2cc26e40802111355g607b496er6cd76582f596fbb5@mail.gmail.com"
type="cite">
<pre wrap="">On Feb 11, 2008 7:49 PM, Blake Hudson <a class="moz-txt-link-rfc2396E" href="mailto:blake@ispn.net"><blake@ispn.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">You may want to review the thread from the beginning. My network currently
has 10,000+ DHCP clients (and I plan on accommodating double that within the
lifetime of this server). I have a beefy server (4x 3.0GHz Xeon, 2x 15k
RAID1) and it was only able to reliably handle 10 to 20 4-way discover
</pre>
</blockquote>
<pre wrap=""><!---->
Isn't that too much CPU power, too little HDD power for this job?
</pre>
</blockquote>
<br>
The server has eight directly attached 147GB 15k drives... it just
happens that the leases file is on a RAID 1 array. Without fsyncs, the
next limiting factor is CPU power... which I hit very quickly at around
40 4-way handshakes a second (unfortunately dhcpd is not
multithreaded). I have not been able to accurately measure 2-way
handshakes after removing the fsync code. I'm guessing it's 5,000 or
more per second... way more than I need.<br>
<br>
<blockquote
cite="mid:b2cc26e40802111355g607b496er6cd76582f596fbb5@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">handshakes a second, 2-way handshakes were maybe double or triple those
numbers. When pounded by DHCP requests, it's possible that even less are
processed in a timely manner due to collisions, timeouts, etc.
The potential convergence time concerns me if there were an enterprise wide
prolonged outage. Increasing the lease time means less leases processed on a
regular basis (not as much of a concern) as well as reducing the need for a
4 way handshake and being able to use a 2 way handshake if a prolonged
outage occurs (my main concern I'd like to accommodate).
</pre>
</blockquote>
<pre wrap=""><!---->
I just read the thread and the disk IO indeed changes the game. ;)
Still, the gap between theoretical top performance and actual
performance seems extreme.
Even if you have the requirement that leases have to be committed to
disk before you respond to the client.
</pre>
</blockquote>
<br>
fsyncs are the most I/O intensive operation you can perform on magnetic
media. If I remember correctly it takes at least 2 full rotations of
the disk for an fsync to occur, although it may take longer to commit
more data. This is were solid state rules over magnetic storage. <br>
<br>
</body>
</html>