Basic performance results and benchmark runs

Results presented here showing top performance of Kea and:

• uses basic Kea configuration
• simplest traffic characteristics
• all rates calculated here will be used to run longer running tests and real file scenarios

Kea configuration

Kea is using the simplest configuration possible.

• one subnet with one pool (/8 for v4 and /64 for v6)
• no options
• no host reservations
• no client classification
• leases lifetime longer than test duration
• default values everywhere we can (e.g. congestion control disabled, LFC enabled for memfile)

Traffic characteristics

perfdhcp generates simples DORA/SARR exchanges without any additional options or option requests. Normally we use 500mln of clients (to not repeat any of them) unless it's stated differently in test description.

Testing methodology

Each test is being executed 9 times, highest and lowest results are ignored, final result of the test is calculated as average out of 7 remaining results.
History of those results is in History of basic results

Basic performance of memfile backend in non-persistent mode

Kea can run in special mode, when it's using memfile but writing to the file is disabled. Everything is kept in memory (similar to keeping memfile on ramdisk).
Kea configuration, traffic specification and testing methodology is the same as for basic results. Reason why it's in separated set it's because it can't be compared with other backends and we strongly discourage people to use this mode. Kea will loose every saved lease on restart.
Running Kea with memfile with non-persist option set to False is NOT RECOMMENDED!

This section provides insight into how kea works second by second during longer running tests.
Thanks to this data visualization we can:

• Detect regularly occurring problems
• Find out how processes like LFC impact Kea performance
• Check how different database backends works

Different Thread settings

How all Kea backends operate with higher number of threads. For now testing setup is limited to 12 threads.

• uses basic Kea configuration
• simplest traffic characteristics
• all rates calculated here will be used to run longer running tests and real file scenarios

Kea configuration (similar to basic tests)

• configuration, other than thread count, is exactly the same as in tests "Basic results"

How various ways of host reservations configurations affect Kea performance

Each test has additional description

Test name: memfile multi threading reservations default global 30 mysql v4

How 3000 (30% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default global 30 mysql v6

How 3000 (30% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default global 30 postgresql v4

How 3000 (30% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations default global 30 postgresql v6

How 3000 (30% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations default global 30 memfile v4

How 3000 (30% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default global 30 memfile v6

How 3000 (30% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default global 100 mysql v4

How 10000 (100% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default global 100 mysql v6

How 10000 (100% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default global 100 postgresql v4

How 10000 (100% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations default global 100 postgresql v6

How 10000 (100% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations default global 100 memfile v4

How 10000 (100% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default global 100 memfile v6

How 10000 (100% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default subnet 30 mysql v4

How 3000 (30% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default subnet 30 mysql v6

How 3000 (30% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default subnet 30 postgresql v4

How 3000 (30% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations default subnet 30 postgresql v6

How 3000 (30% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations default subnet 30 memfile v4

How 3000 (30% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default subnet 30 memfile v6

How 3000 (30% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default subnet 100 mysql v4

How 10000 (100% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default subnet 100 mysql v6

How 10000 (100% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default subnet 100 postgresql v4

How 10000 (100% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations default subnet 100 postgresql v6

How 10000 (100% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations default subnet 100 memfile v4

How 10000 (100% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default subnet 100 memfile v6

How 10000 (100% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized global 30 mysql v4

How 3000 (30% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized global 30 mysql v6

How 3000 (30% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized global 30 postgresql v4

How 3000 (30% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized global 30 postgresql v6

How 3000 (30% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized global 30 memfile v4

How 3000 (30% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized global 30 memfile v6

How 3000 (30% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized global 100 mysql v4

How 10000 (100% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized global 100 mysql v6

How 10000 (100% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized global 100 postgresql v4

How 10000 (100% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized global 100 postgresql v6

How 10000 (100% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized global 100 memfile v4

How 10000 (100% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized global 100 memfile v6

How 10000 (100% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized subnet 30 mysql v4

How 3000 (30% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized subnet 30 mysql v6

How 3000 (30% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized subnet 30 postgresql v4

How 3000 (30% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized subnet 30 postgresql v6

How 3000 (30% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized subnet 30 memfile v4

How 3000 (30% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized subnet 30 memfile v6

How 3000 (30% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized subnet 100 mysql v4

How 10000 (100% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized subnet 100 mysql v6

How 10000 (100% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized subnet 100 postgresql v4

How 10000 (100% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized subnet 100 postgresql v6

How 10000 (100% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized subnet 100 memfile v4

How 10000 (100% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized subnet 100 memfile v6

How 10000 (100% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default global 150 mysql v4

How 15000 (150% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default global 150 mysql v6

How 15000 (150% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default global 150 postgresql v4

How 15000 (150% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations default global 150 postgresql v6

How 15000 (150% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations default global 150 memfile v4

How 15000 (150% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default global 150 memfile v6

How 15000 (150% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default subnet 150 mysql v4

How 15000 (150% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default subnet 150 mysql v6

How 15000 (150% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations default subnet 150 postgresql v4

How 15000 (150% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations default subnet 150 postgresql v6

How 15000 (150% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations default subnet 150 memfile v4

How 15000 (150% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations default subnet 150 memfile v6

How 15000 (150% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: None, default settings
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized global 150 mysql v4

How 15000 (150% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized global 150 mysql v6

How 15000 (150% of all clients) global reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized global 150 postgresql v4

How 15000 (150% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized global 150 postgresql v6

How 15000 (150% of all clients) global reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized global 150 memfile v4

How 15000 (150% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized global 150 memfile v6

How 15000 (150% of all clients) global reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized subnet 150 mysql v4

How 15000 (150% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized subnet 150 mysql v6

How 15000 (150% of all clients) subnet reservations kept in mysql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 14 threads, queue size 160 per thread

Test name: memfile multi threading reservations optimized subnet 150 postgresql v4

How 15000 (150% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 8 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized subnet 150 postgresql v6

How 15000 (150% of all clients) subnet reservations kept in postgresql will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 6 threads, queue size 70 per thread

Test name: memfile multi threading reservations optimized subnet 150 memfile v4

How 15000 (150% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Test name: memfile multi threading reservations optimized subnet 150 memfile v6

How 15000 (150% of all clients) subnet reservations kept in memfile will decrease performance (leases in memfile)
Reservation optimization: host-reservation-identifiers set to hw-address, and reservation out-of-pool
MT settings: 4 threads, queue size 4 per thread

Resource consumption of single Kea running with different backends

Each test has additional description

Test name: resources consumption memfile v6 multi

Checking if memory usage still grows when there are no new clients, just returning. 10mln unique clients. 4 threads, queue size 4 per thread Memory usage should stop growing after ~1000.

Test name: resources consumption memfile v4 multi

Checking if memory usage still grows when there are no new clients, just returning. 10mln unique clients. 4 threads, queue size 4 per thread Memory usage should stop growing after ~1400.

Test name: resources consumption mysql v6 multi

Checking if memory usage still grows when there are no new clients, just returning. 10mln unique clients. 14 threads, queue size 160 per thread Memory usage should stop growing after ~1000.

Test name: resources consumption mysql v4 multi

Checking if memory usage still grows when there are no new clients, just returning. 10mln unique clients. 14 threads, queue size 160 per thread Memory usage should stop growing after ~1400.

Test name: resources consumption postgresql v6 multi

Checking if memory usage still grows when there are no new clients, just returning. 10mln unique clients. 6 threads, queue size 70 per thread Memory usage should stop growing after ~1000.

Test name: resources consumption postgresql v4 multi

Checking if memory usage still grows when there are no new clients, just returning. 10mln unique clients. 8 threads, queue size 70 per thread Memory usage should stop growing after ~1400.

How different subnet/network configuration affect Kea performance

Each test has additional description

Test name: multi threading multiple subnets memfile 100 v4

How adding 200 subnets will decrease performance.
4 threads, queue size 4 per thread

Test name: multi threading multiple subnets memfile 200 v4

How adding 200 subnets will decrease performance.
4 threads, queue size 4 per thread

Test name: multi threading multiple subnets mysql 100 v4

How adding 200 subnets will decrease performance.
14 threads, queue size 160 per thread

Test name: multi threading multiple subnets mysql 200 v4

How adding 200 subnets will decrease performance.
14 threads, queue size 160 per thread

Test name: multi threading multiple subnets postgresql 100 v4

How adding 200 subnets will decrease performance.
8 threads, queue size 70 per thread

Test name: multi threading multiple subnets postgresql 200 v4

How adding 200 subnets will decrease performance.
8 threads, queue size 70 per thread

This page contain history of basic performance tests result. It's kept so we could detect changes in performance.
All charts have their's own scale, if this would be unified for comparision between backends changes in performance of slower backends would be harder to notice. For comparision between backends please go to basic results.

Performance testing report

Welcome to Kea performance testing report, this document is generated automatically after each test run.
In section "Testing setup" we describe anything that imply to entire testing. Specific test details and explanation are placed with results.

Testing setup

Network

Testing is done in ISC internal network and it's 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.5 LTS
• Mysql - 5.7.34-0ubuntu0.18.04.1
• Postgresql - 190ubuntu0.1
• boost - 1.65.1.0ubuntu1
• openssl - 1.1.1-1ubuntu2.1~18.04.9
• Kea - 1.8.2-isc0001520201206093433

Kea performance testing principles

• All results are calculated with assumption that 2.5% drop rate in the network is acceptable.
• If Kea is using database backed - database is always located on the same system as Kea.
• Packet is considered as dropped when response from server reach perfdhcp after 2 or more seconds from sending initial packet.

Kea configuration

Configuration vary between tests and test types, details will be described with tests results.
If not stated explicitly in test description Kea is using default configuration values.

Database configuration

• MySQL is configured with innodb_flush_log_at_trx_commit=2 as described in KEA ARM. Nothing else waas changed
• Postgresql configuration uses default values.

Clients behaviour

If not stated differently in the test there are no releases/renews/rebinds only basic 4 message exchange (SARR and DORA).
Each client perform exchange just once. Number of clients is 500mln.
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

Disclaimers

Performance testing results are volatile, multiple factors has to be taken to 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, guaranteed.
Kea development team takes performance and stability very seriously - please report on kea-users mailing lists any irregularities you observed inside your network.

ISC strongly recommends making yourself familiar with Kea performance optimization article.