Source Tar Ball Installation

[David W. Hankins]

On Fri, Feb 27, 2009 at 12:35:02PM +0800, T MANIKANDAN-PKXR74 wrote:
>     and by implementing ping-check off and writing the leases to a ram
> disk instead of Hard disk betters the performance for 10.0/24 subnet
> around 2300 5 way handshakes per second and for 10.0/8 the performance
> remains the same around 92 five way handshakes per second.
>  
>   Is there a way to increase the performance when the subnet is 10.0/8
> why the performance is degrading ?? any help is appreciated. 

That's interesting!

You could also try configuring 10/8 with, say, 256 pool {} statements,
and the 10/8 space divided up into 256 separate ranges.  The pools are
linearly linked together, but it might be interesting to see how (or
if) they divide the lower pool-level list work.  I suspect it would
actually make things worse, but I'm curious.

Anyway, on to my theory of why you're seeing this difference;

The individual pools arrange the leases in sorted doubly-linked linear
lists (head and tail pointers), by state ('free', 'backup', 'active',
etc with different sort keys based on the state).

To improve performance with 10/8 all in a single pool, you will need
to address this memory structure problem.  The point of the sorted
lists is so that at lease delivery time, the server only has to
dereference a single pointer to allocate a lease.  The oldest, best
lease to allocate, is always on the top of the list.  To grant a new
lease to a client that doesn't have an old one in the hash table
already, we just take the oldest lease off the top.

Similarly, we schedule for the nearest-expiring active lease to
conduct expiration events.  So active lease grants still have to be
inserted into their linear list.  Because the code is general for
any lease change action, renewals are actually popped out of the
list and reinserted from the head.  Most pessimal.

I was thinking of replacing these linear lists with heaps.  This would
not be very hard to do in DHCP-4.* since we already have some heap
code in the common library, and there aren't many places where the
lease lists are referenced.

The thing that stops me from doing that is that sometimes we also want
the tail of the list, such as in the failover pool balance code, where
we want to give away 'affinity' leases to the peer that have the best
chance to be reallocated (the most recently expired leases).  So I
wonder if that's the best structure here.

I suppose if I had thought more about it, I would have just switched
to a heap for the active list, since we don't need to inspect its
tail, and left the free/backup lists alone until I could decide.


We could also stand to arrange the pool expiration timer events in a
separate heap, and arrange subnets...better.  These are also both
linear lists right now...we traverse all pools to get the best
expiration time, and we search all subnets to find the first mask
that fits giaddr contents (directly attached subnets benefit from
not having to be searched - the source interface just knows).

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090303/5736a591/attachment.bin>