Kea Performance Tests - 2.0
  • 07 Dec 2021
  • 4 Minutes to read
  • Contributors
  • Dark
  • PDF

Kea Performance Tests - 2.0

  • Dark
  • PDF

Article Summary

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%

Single server, no HA Memfile MySQL PostgreSQL
Single-threaded 11686 2559 2396
Multi-threaded 18977 10135 7441

Then we tested both high-availability modes:

Server pair - Hot Standby Memfile MySQL PostgreSQL
Single-threaded 5621 692 1518
Multi-threaded 11962 7416 6768
Server pair - Load Balancing Memfile MySQL PostgreSQL
Single-threaded 5532 575 427
Multi-threaded 12417 9981 5891
Impact of multi-threading

Multithreading approximately doubles performance for the fastest Memfile deployments, and can improve performance of the slower database backend alternatives by as much as 10x.

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:

Single server, no HA Memfile MySQL PostgreSQL
Single-threaded 13612 1218 2355
Multi-threaded 37956 11191 7792

Then we tested both high-availability modes:

Server pair - Hot Standby Memfile MySQL PostgreSQL
Single-threaded 5621 486 1400
Multi-threaded 12417 8163 6800
Server pair - Load Balancing Memfile MySQL PostgreSQL
Single-threaded 5561 575 486
Multi-threaded 12417 10370 6442

Testing setup


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 -
  • openssl - 1.1.1-1ubuntu2.1~18.04.13
  • Kea - 1.9.11-isc20210830141610


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.


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.