Dhcp load testing

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dhcp load testing

kraishak
Hi Everyone,

I am using the isc dhcpd on my lab environment so before I use it to my workshop, I want to try load test on it. I created the configuration with sufficient long pool, I tried running perfdhcp tool for load testing as suggested in many google forums and I observed that at a maximum of 10-14 transactions per second(tried with other different tools also), If I increase load the packets are getting dropped, I don't think that is benchmark of ISC dhcp, can any one has idea or any suggestions of how can i increase load handling capacity of the dhcpd service
FYI: I diabled ping check 
Ping check false;
Ping time out 0; 
The above two statements already added to my config file.


Thanks

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Dhcp load testing

Peter Yardley
Take a look at …

https://kb.isc.org/docs/aa-01283

Major bottleneck is disk IO so try to speed that up (raid, flash etc). If using UNIX put the leases file in a mount point with ‘noatime’ enabled. Send the logs to another server using syslog.

> On 31 Oct 2019, at 5:21 am, Kraishak Mahtha <[hidden email]> wrote:
>
> Hi Everyone,
>
> I am using the isc dhcpd on my lab environment so before I use it to my workshop, I want to try load test on it. I created the configuration with sufficient long pool, I tried running perfdhcp tool for load testing as suggested in many google forums and I observed that at a maximum of 10-14 transactions per second(tried with other different tools also), If I increase load the packets are getting dropped, I don't think that is benchmark of ISC dhcp, can any one has idea or any suggestions of how can i increase load handling capacity of the dhcpd service
> FYI: I diabled ping check
> Ping check false;
> Ping time out 0;
> The above two statements already added to my config file.
>
>
> Thanks
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

._--_|\ Peter Yardley |
/ \ Senior Network Engineer | [hidden email]
\_.--._* Information Technology Division, | Ph: +61 2 9514-2358
. v University of Technology, Sydney.| Fax: +61 2 9514-4327



UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. Think. Green. Do. Please consider the environment before printing this email.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Dhcp load testing

dave c
That part about sending your logs elsewhere via syslog is extremely critical.

The leases file will be an append only operation and can handle a pretty hefty workload, as long
as the diskio subsystem isn't also dragging attention to syslog writing to local disks several
times for _every_ dhcp transaction.

Send syslog elsewhere and it should dramatically improve performance for you.

A trick I've done in the very distant past when disk speeds were horrible was to create a
virtual disk in ram (ramdisk), let the leases file live there and once a minute or so, copy the
leases file to a persistent disk.

I'd think that would only be needed for extremely busy systems. I've routinely managed leases
for around 75k files on a low powered Linux VM... but only when I turned off local syslog :) If
you needed to manage a half million or so, maybe a ramdisk might be needed... but at that point
I'd start looking at lease times to reduce transaction cycles and whether it makes more sense to
split the environment to multiple DHCP servers so that you don't have as many eggs in a single
basket (or pair of baskets in an active/active configuration). I went from a pair of servers
each handling 75k or so leases to 5 sets of paired active/active servers each handling about 1/4
to 1/6 of what the two combined used to have.

Dave

On 10/30/19 20:02, Peter Yardley wrote:

> Take a look at …
>
> https://kb.isc.org/docs/aa-01283
>
> Major bottleneck is disk IO so try to speed that up (raid, flash etc). If using UNIX put the
> leases file in a mount point with ‘noatime’ enabled. Send the logs to another server using syslog.
>
>  > On 31 Oct 2019, at 5:21 am, Kraishak Mahtha <[hidden email]> wrote:
>  >
>  > Hi Everyone,
>  >
>  > I am using the isc dhcpd on my lab environment so before I use it to my workshop, I want to
> try load test on it. I created the configuration with sufficient long pool, I tried running
> perfdhcp tool for load testing as suggested in many google forums and I observed that at a
> maximum of 10-14 transactions per second(tried with other different tools also), If I increase
> load the packets are getting dropped, I don't think that is benchmark of ISC dhcp, can any one
> has idea or any suggestions of how can i increase load handling capacity of the dhcpd service
>  > FYI: I diabled ping check
>  > Ping check false;
>  > Ping time out 0;
>  > The above two statements already added to my config file.
>  >
>  >
>  > Thanks
>  > _______________________________________________
>  > dhcp-users mailing list
>  > [hidden email] <mailto:[hidden email]>
>  > https://lists.isc.org/mailman/listinfo/dhcp-users
>
> ._--_|\ Peter Yardley |
> / \ Senior Network Engineer | [hidden email] <mailto:[hidden email]>
> \_.--._* Information Technology Division, | Ph: +61 2 9514-2358
> . v University of Technology, Sydney.| Fax: +61 2 9514-4327
>
>
>
> UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments
> may contain confidential information. If you are not the intended recipient, do not read, use,
> disseminate, distribute or copy this message or attachments. If you have received this message
> in error, please notify the sender immediately and delete this message. Any views expressed in
> this message are those of the individual sender, except where the sender expressly, and with
> authority, states them to be the views of the University of Technology Sydney. Before opening
> any attachments, please check them for viruses and defects. Think. Green. Do. Please consider
> the environment before printing this email.
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Dhcp load testing

Simon Hobson
Dave C <[hidden email]> wrote:

> That part about sending your logs elsewhere via syslog is extremely critical.

As a halfway house, configure syslog for async logging.
The default is (on every system I've worked on) for sync logging which as you point out means a lot of disk thrashing.

> A trick I've done in the very distant past when disk speeds were horrible was to create a virtual disk in ram (ramdisk), let the leases file live there and once a minute or so, copy the leases file to a persistent disk.

SSDs have got bigger, faster, cheaper over time. Switching to SSDs would make a huge difference - as long as the whole system supports TRIM and you make sure there's plenty of free space*.

* TRIM means that the SSD knows when a block is no longer part of a file (so it can be queued for background erasure), and having a large amount of free space gives a large buffer of free blocks for the drive to use so minimising the chance of running out at times of peak activity.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users