kea-dhcp4 - benchmarks (memfile and mysql)

Tomek Mrugalski tomasz at isc.org
Tue Sep 16 19:18:13 UTC 2014


On 16.09.2014 16:15, Chaigneau, Nicolas wrote:
> Hello again, and first thanks for the detailed answer.
> 
> First about the memfile mode.
> 
> I agree the 4100 leases/s I measured is a good value, probably more 
> than enough. Note that at that rate, I'm running at a bit less than 
> 100% CPU on the core handling the process. I don't experience any 
> packet loss (if I try a higher lease rate/s, then I reach 100% CPU, 
> and at this point things start to get ugly).
> 
> For reference, this was with a lease file on RAMDISK, replicated 
> through DRBD in order to ensure there is no data lost in case of 
> hardware failure.
> 
> I also tested the memfile with "persist" set to false (disk 
> operations disabled); in this case, I get up to 4900 leases/s.
> Again, the limiting factor for me is the CPU; I assume I would get
> more on a more powerful hardware.
Interesting. Our 8000 value was measured almost a year ago. We did add
extra code since then, but I would have thought the impact would be
smaller. But the differences are probably due to other hardware
configuration.

> About the possibility of writing the lease file only on shutdown: 
> that may be interesting to some, but that's not a compromise we can 
> settle with. Hardware failures can happen, even sometimes software 
> crash (not to say it would happen with Kea, but we have to assume
> the worst). We want to be able to recover the leases in such a case.
Sure. This is not something we would recommend users to do in normal
circumstances, just as mitigation/recovery technique for a disaster that
already happened. But I see that the performance gain (extra 800
leases/sec) is not that big, so maybe it isn't worth the effort...

> About postgreSQL: I have no plans to test with postgreSQL for now. 
> (not that it's not a good DB, but time is limited, so unless there 
> are very good reasons to assume it would be better than MySQL, I 
> won't be able to... sorry)
Understood.

> The fact that Kea is not multi-threaded is disappointing. Our server 
> has 24 cores, 23 of which are hence sitting idle... and only one at 
> almost 100% CPU (when testing the limit on a memfile). I hope you
That's somewhat disappointing, I agree. On the other hand, if you get
the performance you need on a single core, the desire to use other cores
is somewhat lessened. Also, as Francis said, it's not about explicitly
going for multiple threads, just to be able to use more cores.

> can add support for multiple cores in the future :) (any idea when
> this "one day" might be ? I won't hold you to it, this is just to get
> a rough estimate)
We will do it for sure, the question is not if, but when. Obviously, I
can't make any specific promises, but for now we have plans made until
summer 2015 and multi-process support is currently not expected in that
timeframe. After we reach 1.0, we'll definitely be looking at the next
feature to implement and taking advantage of multiple cores is
definitely one of potential next features.

Personally, I'm a bit hesitant to implement multi-core support as soon
as possible. There are large deployments that could benefit from it, but
a typical user will never need it and the current performance should be
sufficient. On the other hand, there will be lots of complications with
multi-process architecture, so we're likely looking at additional pains
experienced by both developers and users.

Having said that, we're an open source shop. It is unlikely, but
possible that someone will develop such support and send us a patch. On
the other hand, ISC is actively looking for Kea sponsors. It is possible
that someone come in to us and say: Here's $$$$, do the multi-core thing
sooner.

Tomek


More information about the kea-dev mailing list