Source Tar Ball Installation

[T MANIKANDAN-PKXR74]

Thanks for all your response.

Here is the Server Specification.


I tersted on different Hardware

1. Intel Pentium 4/1GB RAM
2. Dual Core DL320/ 1 GB RAM
3. 2 Way Quad Core SunBlade x6240 /4 GB RAM

With default settings I got around 26 Five way handshakes for Intel
Pentium 4, 42 for Dual core and 92 for Quad Core. 
After Implementing the below changes In all the Above h/w  I got the
Performance 25X better.

1. Break the Larger Subnet into smaller Pools
2. Disable Ping Check 
3. Write the Lease to RAM Disk
4. Disable /Var/log/messages for dhcpd

 around 600 for Intel 
1000 for Dual core
2300 for Quad Core 

The Tool used for testing is dhcperf.

Regards
Mani

-----Original Message-----
From: dhcp-users-bounces at lists.isc.org
[mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Brad Dameron
Sent: Wednesday, March 04, 2009 2:35 AM
To: Users of ISC DHCP
Subject: RE: Source Tar Ball Installation


Also I never tested up to a /8. I did test up to a /14. We just wanted
to support 250k IP's per server pair. I broke these into 16 /18's for
testing.

Brad Dameron
Senior Systems Engineer
Clearw're



-----Original Message-----
From: dhcp-users-bounces at lists.isc.org
[mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of David W. Hankins
Sent: Tuesday, March 03, 2009 12:02 PM
To: Users of ISC DHCP
Subject: Re: Source Tar Ball Installation

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
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users