Baseline performance tests results

Results presented here show the maximum throughput of Kea using:

• A very basic Kea configuration
• The simplest traffic characteristics
• Results presented here showing top performance of single Kea setup (one server) and High Availability setup (two connected servers in the network)
• All tests here are type A - which are calculating top performance. Calculated rate will be used in tests type B.

Kea configuration

Tests here are using simplest configuration possible with default 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.

Basic performance of memfile backend in non-persistent mode

Kea can run in a special mode, using the memfile lease backend without writing leases to disk. Everything is kept in memory (similar to keeping memfile on ramdisk).
Kea configuration, traffic specification and testing methodology is otherwise the same as with the basic test. The reason this data is presented separately is because it can't be compared with the results using the other backends. We strongly discourage people from using this mode in production because Kea will not retain information on existing leases after restarting.
Running Kea with memfile lease backend with persist option set to False is NOT RECOMMENDED!

Different Thread settings

This test measures how the different Kea backends respond to variation in the number of threads used.

• Using the basic Kea configuration described in the baseline test report
• Uses the simplest traffic characteristics
• We use the thread count settings ("thread-pool-size" and "packet-queue-size") that provide the optimum results from this test to establish the thread count configuration for the other tests.
• First set of charts (bar) are testing performance in relation to value of "thread-pool-size".
• Second set of charts (line) are using value of "thread-pool-size" which had highest results and testing performance in relation to "packet-queue-size" value.

Kea configuration (similar to the baseline tests)

• Other than thread count, the configuration is exactly the same as that used in the "Baseline results" test.

How various ways of host reservations configurations affect Kea performance

Each test has an additional description. Set of bar charts display results comparison of single runs presented in second part of this page.

Scenario: 1. Test key words: 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

Scenario: 2. Test key words: 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

Scenario: 3. Test key words: 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

Scenario: 4. Test key words: 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

Scenario: 5. Test key words: 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

Scenario: 6. Test key words: 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

Scenario: 7. Test key words: 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

Scenario: 8. Test key words: 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

Scenario: 9. Test key words: 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

Scenario: 10. Test key words: 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

Scenario: 11. Test key words: 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

Scenario: 12. Test key words: 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

Scenario: 13. Test key words: 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

Scenario: 14. Test key words: 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

Scenario: 15. Test key words: 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

Scenario: 16. Test key words: 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

Scenario: 17. Test key words: 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

Scenario: 18. Test key words: 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

Scenario: 19. Test key words: 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

Scenario: 20. Test key words: 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

Scenario: 21. Test key words: 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

Scenario: 22. Test key words: 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

Scenario: 23. Test key words: 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

Scenario: 24. Test key words: 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

Scenario: 25. Test key words: 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

Scenario: 26. Test key words: 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

Scenario: 27. Test key words: 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

Scenario: 28. Test key words: 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

Scenario: 29. Test key words: 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

Scenario: 30. Test key words: 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

Scenario: 31. Test key words: 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

Scenario: 32. Test key words: 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

Scenario: 33. Test key words: 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

Scenario: 34. Test key words: 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

Scenario: 35. Test key words: 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

Scenario: 36. Test key words: 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

Scenario: 37. Test key words: 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

Scenario: 38. Test key words: 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

Scenario: 39. Test key words: 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

Scenario: 40. Test key words: 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

Scenario: 41. Test key words: 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

Scenario: 42. Test key words: 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

Scenario: 43. Test key words: 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

Scenario: 44. Test key words: 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

Scenario: 45. Test key words: 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

Scenario: 46. Test key words: 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

Scenario: 47. Test key words: 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

Scenario: 48. Test key words: 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

Scenario: 49. Test key words: 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

Scenario: 50. Test key words: 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

Scenario: 51. Test key words: 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

Scenario: 52. Test key words: 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

Scenario: 53. Test key words: 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

Scenario: 54. Test key words: 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

Scenario: 55. Test key words: 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

Scenario: 56. Test key words: 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

Scenario: 57. Test key words: 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

Scenario: 58. Test key words: 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

Scenario: 59. Test key words: 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

Scenario: 60. Test key words: 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

Scenario: 61. Test key words: 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

Scenario: 62. Test key words: 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

Scenario: 63. Test key words: 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

Scenario: 64. Test key words: 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

Scenario: 65. Test key words: 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

Scenario: 66. Test key words: 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

Scenario: 67. Test key words: 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

Scenario: 68. Test key words: 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

Scenario: 69. Test key words: 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

Scenario: 70. Test key words: 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

Scenario: 71. Test key words: 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

Scenario: 72. Test key words: 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 an additional description.

Scenario: 1. Test key words: 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.

Scenario: 2. Test key words: 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.

Scenario: 3. Test key words: 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.

Scenario: 4. Test key words: 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.

Scenario: 5. Test key words: 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.

Scenario: 6. Test key words: 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 an additional description

Scenario: 1. Test key words: multi threading multiple subnets memfile 100 v4

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

Scenario: 2. Test key words: multi threading multiple subnets memfile 200 v4

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

Scenario: 3. Test key words: multi threading multiple subnets mysql 100 v4

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

Scenario: 4. Test key words: multi threading multiple subnets mysql 200 v4

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

Scenario: 5. Test key words: multi threading multiple subnets postgresql 100 v4

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

Scenario: 6. Test key words: multi threading multiple subnets postgresql 200 v4

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

Real life scenarios - This set of tests measure how using various features of Kea affect performance.

Please view the mouseover text for additional test scenario information.

Scenario: 1. Test key words: legal logging hook basic memfile v4 multi

How enabling default legal logging will impact performance
4 threads, queue size 4 per thread

Scenario: 2. Test key words: legal logging hook basic memfile v6 multi

How enabling default legal logging will impact performance
4 threads, queue size 4 per thread

Scenario: 3. Test key words: lease cache feature memfile disabled v4 multi

In this tests clients are renewing assigned address immediately after it was assigned. Such behaviour is against protocol but it happens. Lease cache feature help mitigate misbehaving clients effects on Kea. Please comapre traffic details with test below.Multi threading settings:
4 threads, queue size 4 per thread

Scenario: 4. Test key words: lease cache feature memfile enabled v4 multi

How enabling lease cache ("cache-threshold": 0.5 on global level) will impact performance, traffic details should be directly compared with charts above with feature disabled.Multi threading settings:
4 threads, queue size 4 per thread

Scenario: 5. Test key words: lease cache feature memfile disabled v6 multi

In this tests clients are renewing assigned address immediately after it was assigned. Such behaviour is against protocol but it happens. Lease cache feature help mitigate misbehaving clients effects on Kea. Please comapre traffic details with test below.Multi threading settings:
4 threads, queue size 4 per thread

Scenario: 6. Test key words: lease cache feature memfile enabled v6 multi

How enabling lease cache ("cache-threshold": 0.5 on global level) will impact performance, traffic details should be directly compared with charts above with feature disabled.Multi threading settings:
4 threads, queue size 4 per thread

This section provides insight into how Kea performs 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 work

Scenario: 1. Test key words: long running memfile v4 multi

Check how Kea response rates changes over longer time of maximum load.
Multi threading settings:
4 threads, queue size 4 per thread

Scenario: 2. Test key words: long running memfile v6 multi

Check how Kea response rates changes over longer time of maximum load.
Multi threading settings:
4 threads, queue size 4 per thread

Scenario: 3. Test key words: long running mysql v4 multi

Check how Kea response rates changes over longer time of maximum load.
Multi threading settings:
14 threads, queue size 160 per thread

Scenario: 4. Test key words: long running mysql v6 multi

Check how Kea response rates changes over longer time of maximum load.
Multi threading settings:
14 threads, queue size 160 per thread

Scenario: 5. Test key words: long running postgresql v4 multi

Check how Kea response rates changes over longer time of maximum load.
Multi threading settings:
8 threads, queue size 70 per thread

Scenario: 6. Test key words: long running postgresql v6 multi

Check how Kea response rates changes over longer time of maximum load.
Multi threading settings:
6 threads, queue size 70 per thread

Scenario: 7. Test key words: long running with renew memfile v4 multi

Check how Kea response rates changes over longer time sending renew messages.
Multi threading settings:
4 threads, queue size 4 per thread

Scenario: 8. Test key words: long running with renew memfile v6 multi

Check how Kea response rates changes over longer time sending renew messages.
Multi threading settings:
4 threads, queue size 4 per thread

This page contains a history of the baseline performance testing results to help in detecting changes in performance.
All charts have their own scale. Although comparison would be easier if we used the same scale across all charts, it would be harder to see the changes in performance for the slower backends. For comparison between backends please go to baseline results.

Performance testing report

Welcome to the Kea performance testing report, this document is generated automatically after each test run.
In section "Testing setup" we describe the common factors that apply to all tests. Specific test details and explanations can be found with the results.

Kea performance test types

All tests in this report can be divided into two groups. First type (A) is where we are calculating top performance and second (B) is where we are running Kea with different features, settings, longer periods of time while generating traffic calculated in previous tests (A) to observe stability and performance penalties of various configurations and features.

How top performance is calculated

Calculating top performance is multistage process, with couple assumptions:

• We use as simple config as possible, mostly with default settings.
• We are gradually increasing generated traffic rate higher and higher until reaching point where packet drop rate is 2,5% (meaning 2,5% of all responses send by server reached client in time longer than 1 second).
• 2,5% drop rate was chosen because it's perfect threshold between not overloaded server (0% drop rate will always beg the question "can we go higher?") and huge overload when most of packets are lost.

Report layout

• In "Single Kea and HA setup" tab we present testing results for single Kea server and for two Kea servers running in High Availability configuration. Those are tests type (A) that are calculating performance.
• In "Multi-threading settings" tab we present how different multi-threading settings ("thread-pool-size" and "packet-queue-size") affect performance for all three lease backends. Those are tests type (A) that are calculating performance.
• In "Host Reservations" tab we present performance degradation of using host-reservations and it's different settings (e.g. difference between out of pool and in pool reservation, or compare subnet and global reservations). Those are tests type (B) that are using previously calculated traffic rates.
• Most of the Kea users will run it with multiple subnets or shared networks, "Subnets" tab present Kea performance configured with hundreds subnets and networks. Those are tests type (B) that are using previously calculated traffic rates.
• Tabs "Resource Consumption" and "Stability" present traffic details, CPU, and MEM utilization over longer time for all leases backends. Those are tests type (B) that are using previously calculated traffic rates.
• "Various Features" tab contain testing results for various features like for example forensic logging. Those are tests type (B) that are using previously calculated traffic rates.
• "Non-persist memfile" tab contain Kea performance charts while using memfile backend without saving leases to file. Those are tests type (A) that are calculating performance.
• "History of basic results" gather history of tests displayed "Single Kea and HA setup" to track performance changes over time.

Testing setup

Network

Testing is performed in ISC's internal network and uses 3 systems. Two are running Kea and database backends (specs 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.34-0ubuntu0.18.04.1
• Postgresql - 190ubuntu0.1
• boost - 1.65.1.0ubuntu1
• openssl - 1.1.1-1ubuntu2.1~18.04.9
• Kea - 1.9.8-isc0034220210524113122

Test Design

• 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.

Kea configuration

Configurations vary between tests and test types, details are described with the test results.
If not stated explicitly in the test description Kea has default configuration values.

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.

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