Watching performance on a DHCP Server

[Blake Hudson]

-------- Original Message  --------
Subject: Re: Watching performance on a DHCP Server
From: David W. Hankins <David_Hankins at isc.org>
To: dhcp-users at isc.org
Date: Monday, February 11, 2008 10:39:40 AM
> On Fri, Feb 08, 2008 at 05:44:39PM -0600, Blake Hudson wrote:
>   
>> The pros of async are that I can spend much less on server hardware, the 
>> cons being that I might lose 5 seconds (default commit time for ext3) of 
>> leases (single digits?) if my server were to freeze (again making the 
>> same assumptions about hardware failure).
>>     
>
> It's impossible to say what will go on in those 5 seconds; it could
> have been only one client, it could have been _all of them_.  These
> days if an ethernet switch gets power cycled, all the clients will
> renew early as soon as they get link back.  It's impossible to say
> what events will "coincidentally" lead up to a failure.
>
> Once beyond the failure, you get into all sorts of client behaviour
> resonance; clients start DECLINEing leases that are already in use,
> if they are capable of that, and once a lease is DECLINEd it is never
> used again unless reset by the operator or no other leases are
> available.
>
>   
>> I'd love to see this available as an option left up to the server 
>> administrator. I'll take a gander at the source next week and see 
>> exactly what it might take. Any changes I make will probably not be as 
>> useful as I'd prefer to stick with the src rpm provided by my 
>> distribution (Fedora), which is currently 3.0.x based.
>>     
>
> I don't think the sources in question have changed much at all between
> 3.0.x and 4.1.x, but if you could draw your diff against 4.1.0a1, that
> would be appreciated.
>
>   

I reviewed the code in 3.0.x and it's very simple. The code in 4.1.x 
changes a bit with the queuing of ACKs. Though it looks like some of the 
framework I'm looking for may already be integrated, but not 
configurable yet, in the 4.1 code.

The 4.1 code takes care of my main concern, but I see a few questions:
fflush then fsync or fflush and forget.
If fsync, when? - based on number of leases (how many) or timer (how long)?

I'm guessing that the performance difference between no fsyncs and 
fsyncs every n leases is fairly small, making my code largely 
unnecessary. If you'd still like to see a diff made, I could certainly 
dust off the C++ skills and make the modifications to the source. I'd 
love to be able to contribute, though I don't know if this is the right 
place given that someone else's code already solves the problem.

-Blake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080211/1c0bd9b1/attachment.html>