Kea Performance Tests - 2.0

Kea 2.0* performance tests results

This is a summary of the basic benchmarks, there are many more test scenarios documented at the report web site.

We measured the maximum throughput of Kea using a very basic Kea configuration, with the simplest traffic characteristics. Other more complex scenarios are documented at the report web site.

*These tests were performed with Kea 1.9.11, which was the release candidate for Kea 2.0.

Simple Configuration

• one subnet with one pool (/8 for v4 and /64 for v6)
• no options
• no host reservations
• no client classification
• lease lifetimes are longer than test duration (to prevent renewals)
• default values are used everywhere possible (e.g. congestion control disabled, LFC enabled for memfile)

Traffic characteristics

ISC's perfdhcp generates simple DORA/SARR exchanges without any additional options or option requests. Normally we configure perfdhcp to simulate up to 500 million different clients (to avoid repeating any client IDs in the course of a single test) unless it's stated differently in the test description.

Kea DHCPv4 Results

We gradually increase the generated traffic rate until the packet drop rate reaches 2.5% (meaning 2.5% of all responses sent by the server do not reach the client within 1 second). The 2.5% drop rate was chosen because it represents a busy, but not overloaded, server. A 0% drop rate does not show the maximum throughput and a higher drop rate is undesirable in production. Figures shown are the number of leases per second achieved before the drop rate exceeded 2.5%

Then we tested both high-availability modes:

Kea DHCPv6 Results

Multi-threading also improved performance for DHCPv6, again particularly when a database backend is used.

First, a single server with no backup or failover system:

Then we tested both high-availability modes:

Testing setup

Network

Testing is performed in ISC's internal network and uses 3 systems. Two are running Kea and database backends (specifications below) and one is running perfdhcp. All three are connected to one VLAN using 1 gigabit ethernet network.

Hardware specs - R340 server

• CPU Intel Xeon E-2146G 3.5GHz 6 cores/12 threads
• 64GB RAM
• 3 x SSDs 446GB each in HW RAID-0 configuration (virtual disk size 1338GB)
• Intel(R) 10GbE 2P X710 Adapter (2 ports)
• Intel(R) GbE 4P I350-t Adapter (4 ports)
• Broadcom Gigabit Ethernet BCM5720 (2 ports)
• OS details, software versions

Tests were executed using:

• OS - Ubuntu 18.04.5 LTS
• Mysql - 5.7.35-0ubuntu0.18.04.1
• Postgresql - 190ubuntu0.1
• boost - 1.65.1.0ubuntu1
• openssl - 1.1.1-1ubuntu2.1~18.04.13
• Kea - 1.9.11-isc20210830141610

Measurement

Maximum performance is measured when packet loss reaches 2.5%. This is assumed to be the maximum acceptable rate of packet loss. If Kea is using a database backend, the database is always located on the same system as Kea. A packet is considered to have been dropped when the response doesn't reach perfdhcp within 2 seconds of the initial packet.

Database configuration

Databases are running on the same systems as Kea (connection delays between Kea server and database is negligible)
MySQL is configured with innodb_flush_log_at_trx_commit=2 as described in the KEA ARM. Nothing else has been changed.
The postgresql configuration uses default values.

Default clients behaviour

Unless stated differently in the test, only the basic 4 message exchange (SARR and DORA) is generated.

• No release/renew or rebind packets are generated.
• Each client performs an exchange just once. Perfdhcp will simulate up to 500 million unique clientIDs so Kea will not recognize any client as returning.
• Messages do not include any additional options, except those necessary to get an address from the DHCP server.

Traffic generator

We use the traffic generator "perfdhcp" for all tests. "perfdhcp" is developed by ISC and is available in Kea source/packages.
We encourage the user to refer to the KEA ARM for more details.

Disclaimers

Performance testing results are volatile, multiple factors have to be taken into account e.g.: hardware, OS type, network, database location (local, remote), compilation CXX flags etc.
The results shown in this report are what we were able to observe within our testing network - they are not necessarily representative of what will be observed in another network.
The Kea development team takes performance and stability very seriously - please report any irregularities you observe on your network to the kea-users mailing list.