Kea Performance

Testing setup

Testing is done in ISC's internal network using 3 systems. Two are running Kea and database backends (specs below) and one is running perfdhcp, all three are connected in 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.4 LTS
  • Mysql - 8.0.19-1ubuntu18.04
  • Postgresql - 190ubuntu0.1
  • boost - 1.65.1.0ubuntu1
  • openssl - 1.1.1-1ubuntu2.1~18.04.5
  • Kea - 1.7.6-isc0018020200403122855

Kea Multithreading Performance Test

The above charts show the results of performance testing of Kea after multithreading was enabled in version 1.7.6. The test is documented more fully in this knowlegebase article: https://kb.isc.org/docs/kea-performance-tests-17-multithreading

  • Leases per second were measured up to a maximum of 2.5% 'drop' rate. Packets were considered dropped if the response was delayed by 2 seconds.
  • All tests using a database backend were done with the database located on the same system as Kea.

Kea configuration

Kea is configured with one subnet, that has just one pool, without any host reservations, client classes or options.
Everywhere we can, we are using default values (e.g. lease reclamation process).
Valid lifetime of leases are longer than duration of each test.

Clients behaviour

There are no releases/renews/rebinds only basic 4 message exchange (SARR and DORA).
Each client perform exchange just once.
Messages do not include any additional options except those necessary to get an address from DHCP server.

Traffic generator

For all tests we are using traffic generator that was developed by ISC and which is available in Kea sources/packages - perfdhcp
We encourage to visit KEA ARM for more details

Lessons learned

  • Fastest backend for Kea is memfile.
  • It's better to use half of available threads to run Kea in multi threading mode.
  • Memfile backend works best with -N4.
  • Databases should work best with higher number of threads, but do not exceed number of cores. Our testing is using -N6.
  • Kea performance is reduced when pool utilization reach 96%.

Disclaimers

Performance testing results are volatile, multiple factors must be taken into account e.g.: hardware, OS type, network, database location (local, remote), compilation CXX flags etc.
Results shown in this report are what we were able to get inside our testing network - those are NOT, by any means, predictive of what you will see in production.
The Kea development team takes performance and stability very seriously - please report on kea-users mailing lists any irregularities you observed inside your network.