DHCP Performance Guide

Tomasz Mrugalski

Marcin Siodelski

This is a companion document for BIND 10 version - 20120817.

Abstract

BIND 10 is a framework that features Domain Name System - (DNS) suite and Dynamic Host Configuration Protocol (DHCP) - servers with development managed by Internet Systems Consortium (ISC). - This document describes various aspects of DHCP performance, - measurements and tuning. It covers BIND 10 DHCP (codename Kea), - existing ISC DHCP4 software, perfdhcp (a DHCP performance - measurement tool) and other related topics.

List of Tables

3.1. Synchronous results
3.2. Asynchronous results
3.3. Estimated performance

Preface

Table of Contents

Acknowledgements

Acknowledgements

ISC would like to acknowledge generous support for - BIND 10 development of DHCPv4 and DHCPv6 components provided - by Comcast.

Chapter 1. Introduction

- This document is in its early stages of development. It is - expected to grow significantly in a near future. It will - cover topics like database backend perfomance measurements, - pros an cons of various optimization techniques and - tools. -

Chapter 2. ISC DHCP 4.x

- TODO: Write something about ISC DHCP4 here. -

Chapter 3. Kea

Table of Contents

Backend performance evaluation

MySQL backend

MySQL tweaks

SQLite-ubench

SQLite tweaks

memfile-ubench

memfile tweaks

Performance measurements

Possible further optimizations

- -

Backend performance evaluation

- Kea will support several different database backends, using - both popular databases (like MySQL or SQLite) and - custom-developed solutions (like in-memory database). BIND 10 - source code features set of performance microbenchmarks. - These are small tools written in C/C++ that simulate expected - DHCP server behaviour and evaluate the performance of - considered databases. As implemented benchmarks are not really - simulating DHCP operation, but rather use set of primitives - that can be used by a real server, they are called - micro-benchmarks. -

Although there are many operations and data types that - server could store in a database, the most frequently used data - type is lease information. Although lease information for IPv4 - and IPv6 differs slightly, it is expected that the performance - differences will be minimal between IPv4 and IPv6 lease operations. - Therefore each test uses lease4 table for performance measurements. -

All benchmarks are implemented as single threaded applications - that take advantage of a single database connection.

- Those benchmarks are stored in tests/tools/dhcp-ubench - directory. This directory contains simplified prototypes for - various DB back-ends that are planned or considered as a - backend engine for BIND10 DHCP. Athough trivial now, they are - expected to evolve into useful tools that will allow users to - measure performance in their specific environment. -

- Currently the following benchmarks are implemented: -

in memory+flat file
SQLite
MySQL

- As they require additional (sometimes heavy) dependencies, they are not - built by default. Actually, their build system is completely separated. - It will be eventually merged with the main BIND10 makefile system, but - that is a low priority for now. -

- All benchmarks will follow the same pattern: -

prepare operation (connect to a database, create a file etc.)
Measure timestamp 0
Commit new lease4 (repeated X times)
Measure timestamp 1
Search for random lease4 (repeated X times)
Measure timestamp 2
Update existing lease4 (repeated X times)
Measure timestamp 3
Delete existing lease4 (repeated X times)
Measure timestamp 4
Print out statistics, based on X and measured timestamps.

- - Although this approach does not attempt to simulate actual DHCP server - operation that has mix of all steps intervening, it answers the - questions about basic database strenghts and weak points. In particular - it can show what is the impact of specific DB optimizations, like - changing engine, optimizing for writes/reads etc. -

- The framework attempts to do the same amount of operations for every - backend thus allowing fair complarison between them. -

MySQL backend

MySQL backend requires MySQL client development libraries. It uses - mysql_config tool (that works similar to pkg-config) to discover required - compilation and linking options. To install required packages on Ubuntu, - use the following command: - -

$ sudo apt-get install mysql-client mysql-server libmysqlclient-dev

- - Make sure that MySQL server is running. Make sure that you have your setup - configured so there is a user that is able to modify used database.

Before running tests, you need to initialize your database. You can - use mysql.schema script for that purpose. WARNING: It will drop existing - Kea database. Do not run this on your production server. Assuming your - MySQL user is kea, you can initialize your test database by: - -

$ mysql -u kea -p < mysql.schema

After database is initialized, you are ready to run the test: -

$ ./mysql_ubench

- - or - -

$ ./mysql_ubench > results->mysql.txt

- - Redirecting output to a file is important, because for each operation - there is a single character printed to show progress. If you have a slow - terminal, this may considerably affect test perfromance. On the other hand, - printing something after each operation is required, as poor DB setting - may slow down operations to around 20 per second. Observant user is expected - to note that initial dots are printed too slowly and abort the test.

Currently all default parameters are hardcoded. Default values can be - overwritten using command line switches. Although all benchmarks take - the same list of parameters, some of them are specific to a given backend - type. To get a list of supported parameters, run your benchmark with -h option: - -

$ ./mysql_ubench -h
-This is a benchmark designed to measure expected performance
-of several backends. This particular version identifies itself
-as following:
-MySQL client version is 5.5.24
-
-Possible command-line parameters:
- -h - help (you are reading this)
- -m hostname - specifies MySQL server to connect (MySQL backend only)
- -u username - specifies MySQL user name (MySQL backend only)
- -p password - specifies MySQL passwod (MySQL backend only)
- -f name - database or filename (MySQL, SQLite and memfile)
- -n integer - number of test repetitions (MySQL, SQLite and memfile)
- -s yes|no - synchronous/asynchronous operation (MySQL, SQLite and memfile)
- -v yes|no - verbose mode (MySQL, SQLite and memfile)
- -c yes|no - should compiled statements be used (MySQL only)
-

- -

MySQL tweaks

One parameter that has huge impact on performance is a a backend engine. - You can get a list of engines of your MySQL implementation by using - -

> show engines;

- - in your mysql client. Two notable engines are MyISAM and InnoDB. mysql_ubench will - use MyISAM for synchronous mode and InnoDB for asynchronous.

SQLite-ubench

SQLite backend requires both sqlite3 development and run-time package. Their - names may vary from system to system, but on Ubuntu 12.04 they are called - sqlite3 libsqlite3-dev. To install them, use the following command: - -

> sudo apt-get install sqlite3 libsqlite3-dev

- - Before running the test the database has to be created. Use the following command for that: -

> cat sqlite.schema | sqlite3 sqlite.db

- - A new database called sqlite.db will be created. That is the default name used - by sqlite_ubench test. If you prefer other name, make sure you update - sqlite_ubench.cc accordingly.

Once the database is created, you can run tests: -

> ./sqlite_ubench

- or -

> ./sqlite_ubench > results-sqlite.txt

SQLite tweaks

To modify default sqlite_ubench parameters, command line - switches can be used. Currently supported parameters are - (default values specified in brackets): -

-f filename - name of the database file ("sqlite.db")
-n num - number of iterations (100)
-s yes|no - should the operations be performend in synchronous (yes) - or asynchronous (no) manner (yes)
-v yes|no - verbose mode. Should the test print out progress? (yes)
-c yes|no - compiled statements. Should the SQL statements be precompiled?

SQLite can run in asynchronous or synchronous mode. This - mode can be controlled by using sync parameter. It is set - using (PRAGMA synchronous = ON or OFF).

Another tweakable feature is journal mode. It can be - turned to several modes of operation. Its value can be - modified in SQLite_uBenchmark::connect(). See - http://www.sqlite.org/pragma.html#pragma_journal_mode for - detailed explanantion.

memfile-ubench

Memfile backend is custom developed prototype backend that - somewhat mimics operation of ISC DHCP4. It uses in-memory - storage using standard C++ and boost mechanisms (std::map and - boost::shared_ptr<>). All database changes are also - written to a lease file. That file is strictly write-only. This - approach takes advantage of the fact that simple append is faster - than edition with potential whole file relocation.

memfile tweaks

To modify default memfile_ubench parameters, command line - switches can be used. Currently supported parameters are - (default values specified in brackets): -

-f filename - name of the database file ("dhcpd.leases")
-n num - number of iterations (100)
-s yes|no - should the operations be performend in synchronous (yes) - or asynchronous (no) manner (yes)
-v yes|no - verbose mode. Should the test print out progress? (yes)

memfile can run in asynchronous or synchronous mode. This - mode can be controlled by using sync parameter. It uses - fflush() and fsync() in synchronous mode to make sure that - data is not buffered and physically stored on disk.

Performance measurements

This section contains sample results for backend performance measurements, - taken using microbenchmarks. Tests were conducted on reasonably powerful machine: -

-CPU: Quad-core Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 logical cores)
-HDD: 1,5TB Seagate Barracuda ST31500341AS 7200rpm (used only one of them), ext4 partition
-OS: Ubuntu 12.04, running kernel 3.2.0-26-generic SMP x86_64
-compiler: g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
-MySQL version: 5.5.24
-SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e

Benchmarks were run in two series: synchronous and - asynchronous. As those modes offer radically different - performances, synchronous mode was conducted for 1000 (one - thousand) repetitions and asynchronous mode was conducted for - 100000 (hundred thousand) repetitions.

Table 3.1. Synchronous results

Backend	Operations	Create	Search	Update	Delete	Average
MySQL	1000	31.603978s	0.116612s	27.964191s	27.695209s	21.844998s
SQLite	1000	61.421356s	0.033283s	59.476638s	56.034150s	44.241357s
memfile	1000	41.711886s	0.000724s	42.267578s	42.169679s	31.537467s

Following parameters were measured for asynchronous mode. - MySQL and SQLite were run with 100 thousand repetitions. Memfile - was run for 1 million repetitions due to much larger performance.

Table 3.2. Asynchronous results

Backend	Operations	Create [s]	Search [s]	Update [s]	Delete [s]	Average [s]
MySQL	100000	10.584842s	10.386402s	10.062384s	8.890197s	9.980956s
SQLite	100000	3.710356s	3.159129s	2.865354s	2.439406s	3.043561s
memfile	1000000 (sic!)	6.084131s	0.862667s	6.018585s	5.146704s	4.528022s

Presented performance results can be computed into operations per second metrics. - It should be noted that due to large differences between various operations (sometime - over 3 orders of magnitude), it is difficult to create a simple, readable chart with - that data.

Table 3.3. Estimated performance

Backend	Create [oper/s]	Search [oper/s]	Update [oper/s]	Delete [oper/s]	Average [oper/s]
MySQL (async)	9447.47	9627.97	9938.00	11248.34	10065.45
SQLite (async)	26951.59	31654.29	34899.70	40993.59	33624.79
memfile (async)	164362.01	1159195.84	166152.01	194299.11	421002.24
MySQL (sync)	31.64	8575.45	35.76	36.11	2169.74
SQLite (sync)	16.28	20045.37	16.81	17.85	7524.08
memfile (sync)	23.97	1381215.47	23.66	23.71	345321.70

Graphical representation of the performance results - presented in table Table 3.3, “Estimated performance”.

Possible further optimizations

- For debugging purposes the code was compiled with -g -O0 - flags. While majority of the time was spent in backend - functions (that was probably compiled with -O2 flags), the - benchmark code could perform faster, when compiled with -O2, - rather than -O0. That is expected to affect memfile benchmark. -

- Currently all operations were conducted on one by one - basis. Each operation was treated as a separate - transaction. Grouping X operations together will potentially - bring almost X fold increase in synchronous operations. - Extension for this benchmark in this regard should be considered. - That affects only write operations (insert, update and delete). Read - operations (search) are expected to be barely affected. -

- Multi-threaded or multi-process benchmark may be considered in - the future. It may be somewhat difficult as only some backends - support concurrent access. -

Chapter 4. perfdhcp

Table of Contents

Purpose

Key features

Command line options

Starting perfdhcp

perfdhcp command line examples

Example: basic usage
Example: rate control
Example: templates

Purpose

- Evaluation of the performance of a DHCP server requires that it - be tested under varying traffic loads. perfdhcp is a testing - tool with the capability to create traffic loads - and generate statistics from the results. Additional features, - such as the ability to send customised DHCP packets, allow it to - be used in a wide range of functional testing. -

Key features

- perfdhcp has a number of command line switches to - control DHCP message exchanges. Currently they fall into - the following categories: -

- Rate control - control how many DHCP exchanges - are initiated within a period of time. The tool can also simulate - best effort conditions by attempting to initiate as many DHCP - packet exchanges as possible within a unit of time. -
- Test exit specifiers - control the conditions for test - completion, including the number of initiated exchanges, - the test period orthe maximum number of dropped packets. -
- Packet templates - specify files containing packet templates that - are used by perfdhcp to create custom DHCP messages. The tool - allows the specification of a number of values indicating - offsets of values within a packet that are set by the tool. -
- Reporting - for each test produce a set of performance data - including the achieved packet exchange rate (server performance). - There are a number of diagnostic selectors available that - enable periodic (intermediate) reporting, printing of packet timestamps, - and the listing of detailed information about internal perfdhcp - states (for debugging). -
- Different mode of operations - specify the DHCP protocol used - (v4 or v6), two-way or four-way exchanges, use of the - Rapid Commit option for DHCPv6. -
- IP layer options - specify the local/remote address, local interface - and local port to be used for communication with DHCP server. -

Command line options

- The following "help" output from the tool describes the - command line switches. This summary also lists the tool's - possible exit codes as well as describing the - error counters printed when the test is complete: -

$ ./perfdhcp -h
-perfdhcp [-hv] [-4|-6] [-r<rate>] [-t<report>] [-R<range>] [-b<base>]
-    [-n<num-request>] [-p<test-period>] [-d<drop-time>] [-D<max-drop>]
-    [-l<local-addr|interface>] [-P<preload>] [-a<aggressivity>]
-    [-L<local-port>] [-s<seed>] [-i] [-B] [-c] [-1]
-    [-T<template-file>] [-X<xid-offset>] [-O<random-offset]
-    [-E<time-offset>] [-S<srvid-offset>] [-I<ip-offset>]
-    [-x<diagnostic-selector>] [-w<wrapped>] [server]
-
-The [server] argument is the name/address of the DHCP server to
-contact.  For DHCPv4 operation, exchanges are initiated by
-transmitting a DHCP DISCOVER to this address.
-
-For DHCPv6 operation, exchanges are initiated by transmitting a DHCP
-SOLICIT to this address.  In the DHCPv6 case, the special name 'all'
-can be used to refer to All_DHCP_Relay_Agents_and_Servers (the
-multicast address FF02::1:2), or the special name 'servers' to refer
-to All_DHCP_Servers (the multicast address FF05::1:3).  The [server]
-argument is optional only in the case that -l is used to specify an
-interface, in which case [server] defaults to 'all'.
-
-The default is to perform a single 4-way exchange, effectively pinging
-the server.
-The -r option is used to set up a performance test, without
-it exchanges are initiated as fast as possible.
-
-Options:
--1: Take the server-ID option from the first received message.
--4: DHCPv4 operation (default). This is incompatible with the -6 option.
--6: DHCPv6 operation. This is incompatible with the -4 option.
--a<aggressivity>: When the target sending rate is not yet reached,
-    control how many exchanges are initiated before the next pause.
--b<base>: The base mac, duid, IP, etc, used to simulate different
-    clients.  This can be specified multiple times, each instance is
-    in the <type>=<value> form, for instance:
-    (and default) mac=00:0c:01:02:03:04.
--d<drop-time>: Specify the time after which a request is treated as
-    having been lost.  The value is given in seconds and may contain a
-    fractional component.  The default is 1 second.
--E<time-offset>: Offset of the (DHCPv4) secs field / (DHCPv6)
-    elapsed-time option in the (second/request) template.
-    The value 0 disables it.
--h: Print this help.
--i: Do only the initial part of an exchange: DO or SA, depending on
-    whether -6 is given.
--I<ip-offset>: Offset of the (DHCPv4) IP address in the requested-IP
-    option / (DHCPv6) IA_NA option in the (second/request) template.
--l<local-addr|interface>: For DHCPv4 operation, specify the local
-    hostname/address to use when communicating with the server.  By
-    default, the interface address through which traffic would
-    normally be routed to the server is used.
-    For DHCPv6 operation, specify the name of the network interface
-    via which exchanges are initiated.
--L<local-port>: Specify the local port to use
-    (the value 0 means to use the default).
--O<random-offset>: Offset of the last octet to randomize in the template.
--P<preload>: Initiate first <preload> exchanges back to back at startup.
--r<rate>: Initiate <rate> DORA/SARR (or if -i is given, DO/SA)
-    exchanges per second.  A periodic report is generated showing the
-    number of exchanges which were not completed, as well as the
-    average response latency.  The program continues until
-    interrupted, at which point a final report is generated.
--R<range>: Specify how many different clients are used. With 1
-    (the default), all requests seem to come from the same client.
--s<seed>: Specify the seed for randomization, making it repeatable.
--S<srvid-offset>: Offset of the server-ID option in the
-    (second/request) template.
--T<template-file>: The name of a file containing the template to use
-    as a stream of hexadecimal digits.
--v: Report the version number of this program.
--w<wrapped>: Command to call with start/stop at the beginning/end of
-    the program.
--x<diagnostic-selector>: Include extended diagnostics in the output.
-    <diagnostic-selector> is a string of single-keywords specifying
-    the operations for which verbose output is desired.  The selector
-    keyletters are:
-   * 'a': print the decoded command line arguments
-   * 'e': print the exit reason
-   * 'i': print rate processing details
-   * 'r': print randomization details
-   * 's': print first server-id
-   * 't': when finished, print timers of all successful exchanges
-   * 'T': when finished, print templates
--X<xid-offset>: Transaction ID (aka. xid) offset in the template.
-
-DHCPv4 only options:
--B: Force broadcast handling.
-
-DHCPv6 only options:
--c: Add a rapid commit option (exchanges will be SA).
-
-The remaining options are used only in conjunction with -r:
-
--D<max-drop>: Abort the test if more than <max-drop> requests have
-    been dropped.  Use -D0 to abort if even a single request has been
-    dropped.  If <max-drop> includes the suffix '%', it specifies a
-    maximum percentage of requests that may be dropped before abort.
-    In this case, testing of the threshold begins after 10 requests
-    have been expected to be received.
--n<num-request>: Initiate <num-request> transactions.  No report is
-    generated until all transactions have been initiated/waited-for,
-    after which a report is generated and the program terminates.
--p<test-period>: Send requests for the given test period, which is
-    specified in the same manner as -d.  This can be used as an
-    alternative to -n, or both options can be given, in which case the
-    testing is completed when either limit is reached.
--t<report>: Delay in seconds between two periodic reports.
-
-Errors:
-- tooshort: received a too short message
-- orphans: received a message which doesn't match an exchange
-   (duplicate, late or not related)
-- locallimit: reached to local system limits when sending a message.
-
-Exit status:
-The exit status is:
-0 on complete success.
-1 for a general error.
-2 if an error is found in the command line arguments.
-3 if there are no general failures in operation, but one or more
-  exchanges are not successfully completed.
-
-

Starting perfdhcp

- In order to run a performance test, at least two separate systems - have to be installed: client and server. The first one must have - perfdhcp installed, and the latter must be running the DHCP server - (either v4 or v6). If only single system is available the client - and server can be run on virtual machines (running on the same - physical system) but in this case performance data may be heavily - impacted by the overhead involved in running such the virtual - machines. -

- Currently, perfdhcp is seen from the server perspective as relay agent. - This simplifies its implementation: specifically there is no need to - receive traffic sent to braodcast addresses. However, it does impose - a requirement that the IPv4 - address has to be set manually on the interface that will be used to - communicate with the server. For example, if the DHCPv4 server is listening - on the interface connected to the 172.16.1.0 subnet, the interface on client - machine has to have network address assigned from the same subnet, e.g. -

#ifconfig eth3 172.16.1.2. netmask 255.255.255.0 up

- As DHCP uses low port numbers (67 for DHCPv4 relays and - 547 for DHCPv6), running perfdhcp with non-root privileges will - usually result in the error message similar to this: -

$./perfdhcp -4 -l eth3 -r 100 all
-Error running perfdhcp: Failed to bind socket 3 to 172.16.1.2/port=67
-

- The '-L' command line switch allows the use of a custom local port. - However, although the following command line will work: -

$./perfdhcp -4 -l eth3 -r 100 -L 10067 all

- in the standard configuration no responses will be received - from the DHCP server because the server responds to default relay - port 67. A way to overcome this issue is to run - perfdhcp as root. -

perfdhcp command line examples

- In this section, a number of perfdhcp command line examples - are presented as a quick start guide for new users. For the - detailed list of command line options refer to - the section called “Command line options”. -

Example: basic usage

- If server is listening on interface with IPv4 address 172.16.1.1, - the simplest perfdhcp command line will look like: -

#./perfdhcp 172.16.1.1
-***Rate statistics***
-Rate: 206.345
-
-***Statistics for: DISCOVER-OFFER***
-sent packets: 21641
-received packets: 350
-drops: 21291
-orphans: 0
-
-min delay: 9.022 ms
-avg delay: 143.100 ms
-max delay: 259.303 ms
-std deviation: 56.074 ms
-collected packets: 30
-
-***Statistics for: REQUEST-ACK***
-sent packets: 350
-received packets: 268
-drops: 82
-orphans: 0
-
-min delay: 3.010 ms
-avg delay: 152.470 ms
-max delay: 258.634 ms
-std deviation: 56.936 ms
-collected packets: 0
-

- Here, perfdhcp uses remote address 172.16.1.1 as a - destination address and will use a suitable local interface for - communication. Since, no rate control parameters have been specified, - it will initiate DHCP exchanges at the maximum possible rate. Due to the server's - performance limitation, it is likely that many of the packets will be dropped. - The performance test will continue running until it is - interrupted by the user (with ^C). -

- The default performance statistics reported by perfdhcp have the - following meaning: -

Rate - number of packet exchanges (packet sent - to the server and matching response received from the server) - completed within a second.
sent packets - total number of DHCP packets of - a specific type sent to the server.
received packets - total number of DHCP packets - of specific type received from the server.
drops - number of dropped packets for the - particular exchange. The number of dropped packets is calculated as - the difference between the number of sent packets and number of - response packets received from the server. In some cases, the - server will have sent a reponse but perfdhcp execution ended before - the reponse arrived. In such case this packet will be counted - as dropped.
orphans - number of packets that have been - received from the server and did not match any packet sent by - perfdhcp. This may occur if received packet has been sent - to some other host or if then exchange timed out and - the sent packet was removed from perfdhcp's list of packets - awaiting a response.
min delay - minimum delay that occured between - sending the packet to the server and receiving a reponse from - it.
avg delay - average delay between sending the - packet of the specific type the server and receiving a response - from it.
max delay - maximum delay that occured between - sending the packet to the server and receiving a response from - it.
std deviation - standard deviation of the delay - between sending the packet of a specific type to the server and - receiving response from it.
collected packets - number of sent packets that - were garbage collected. Packets may get garbage collected when - the waiting time for server a response exceeds value set with the - '-d' (drop time) switch. - -d<drop-time>.

- Note: should multiple interfaces on the system running perfdhcp be - connected to the same subnet, the interface to be used for the test - can be specified using either the interface name: -

#./perfdhcp -l eth3

- or a local address assigned to it: -

#./perfdhcp -l 172.16.1.2

Example: rate control

- In the examples above perfdhcp initiates new exchanges with a best - effort rate. With this setting, many packets are expected to be dropped - by the server due to performance limitations. In many cases though, it is - desired to verify that the server can handle an expected (reasonable) rate - without dropping any packets. The following command is an example of such - a test: it causes perfdhcp to initiate 300 four-way exchanges - per second, and runs the test for 60 seconds: -

#./perfdhcp -l eth3 -p 60 -r 300
-***Rate statistics***
-Rate: 256.683 exchanges/second, expected rate: 300 exchanges/second
-
-***Statistics for: DISCOVER-OFFER***
-sent packets: 17783
-received packets: 15401
-drops: 2382
-orphans: 0
-
-min delay: 0.109 ms
-avg delay: 75.756 ms
-max delay: 575.614 ms
-std deviation: 60.513 ms
-collected packets: 11
-
-***Statistics for: REQUEST-ACK***
-sent packets: 15401
-received packets: 15317
-drops: 84
-orphans: 0
-
-min delay: 0.536 ms
-avg delay: 72.072 ms
-max delay: 576.749 ms
-std deviation: 58.189 ms
-collected packets: 0
-

- Note that here, the packet drops for the DISCOVER-OFFER - exchange have been significantly reduced (when compared with the - output from the previous example) thanks to the setting of a - reasonable rate. The non-zero number of packet drops and achieved - rate (256/s) indicate that server's measured performance is lower than 300 leases - per second. A further rate decrease should eliminate most of the packet - drops and bring the achieved rate close to expected rate: -

#./perfdhcp -l eth3 -p 60 -r 100 -R 30
-***Rate statistics***
-Rate: 99.8164 exchanges/second, expected rate: 100 exchanges/second
-
-***Statistics for: DISCOVER-OFFER***
-sent packets: 5989
-received packets: 5989
-drops: 0
-orphans: 0
-
-min delay: 0.023 ms
-avg delay: 2.198 ms
-max delay: 181.760 ms
-std deviation: 9.429 ms
-collected packets: 0
-
-***Statistics for: REQUEST-ACK***
-sent packets: 5989
-received packets: 5989
-drops: 0
-orphans: 0
-
-min delay: 0.473 ms
-avg delay: 2.355 ms
-max delay: 189.658 ms
-std deviation: 5.876 ms
-collected packets: 0
-

- There are now no packet drops, confirming that the server is able to - handle a load of 100 leases/second. - Note that the last parameter (-R 30) configures perfdhcp to simulate - traffic from 30 distinct clients. -

Example: templates

- By default the DHCP messages are formed with default options. With - template files, it is possible to define a custom packet format. -

- The template file names are specified with -T<template-file> - command line option. This option can be specified zero, one or two times. - The first occurence of this option refers to DISCOVER or SOLICIT message - and the second occurence refers to REQUEST (DHCPv4 or DHCPv6) message. - If -T option occurs only once the DISCOVER or SOLICIT message will be - created from the template and the REQUEST message will be created - dynamically (without the template). Note that each template file - holds data for exactly one DHCP message type. Templates for multiple - message types must not be combined in the single file. - The content in template files is encoded in hexadecimal format. - perfdhcp forms the packet by replacing parts of the message buffer read - from the file with variable data such as elapsed time, hardware address, DUID - etc. The offsets where such variable data is placed is specific to the - template file and have to be specified from the command line. Refer to - the section called “Command line options” to find out how to - specify offsets for particular options and fields. With the following - command line the DHCPv6 SOLICIT and REQUEST packets will be formed from - solicit.hex and request6.hex packets: -

#./perfdhcp -6 -l eth3 -r 100 -R 20 -T solicit.hex -T request6.hex -O 21 -E 84 -S 22 -I 40 servers
-***Rate statistics***
-Rate: 99.5398 exchanges/second, expected rate: 100 exchanges/second
-
-***Statistics for: SOLICIT-ADVERTISE***
-sent packets: 570
-received packets: 569
-drops: 1
-orphans: 0
-
-min delay: 0.259 ms
-avg delay: 0.912 ms
-max delay: 6.979 ms
-std deviation: 0.709 ms
-collected packets: 0
-
-***Statistics for: REQUEST-REPLY***
-sent packets: 569
-received packets: 569
-drops: 0
-orphans: 0
-
-min delay: 0.084 ms
-avg delay: 0.607 ms
-max delay: 6.490 ms
-std deviation: 0.518 ms
-collected packets: 0
-

- where the switches have the following meaning: -

two occurences of -O 21 - DUID's last octet - positions in SOLICIT and REQUEST respectively.
-E 84 - elapsed time option position in the - REQUEST template
-S 22 - server id position in the REQUEST - template
-I 40 - IA_NA option position in the REQUEST - template

- The offsets of options indicate where they begin in the packet. - The only exception from this rule is -O<random-offset> - option that specifies the end of the DUID (DHCPv6) or MAC address - (DHCPv4). Depending on the number of simulated clients - (see -R<random-range> command line option) perfdhcp - will be randomizing bytes in packet buffer starting from this - position backwards. For the number of simulated clients - <= 256 only one octet (at random-offset position) - will be ranomized, for the number of clients <= 65536 - two octets (at random-offset and random-offset-1) - will be randmized etc. -