Results presented here showing top performance of Kea and:
Kea is using the simplest configuration possible.
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.
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
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:
How all Kea backends operate with higher number of threads. For now testing setup is limited to 12 threads.
Each test has additional description
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
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
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