[kea-dev] Requirements for the Logging and Diagnostics in Kea

Stephen Morris stephen at isc.org
Thu Apr 9 10:41:17 UTC 2015


On 09/04/15 08:03, Chaigneau, Nicolas wrote:

> 
> This is a very valid concern.
> I added (within a hook) a log of each received and sent packet as described by Tomek, and noticed a very significant drop in performances.
> (by performances here I mean "how many DORA/s can I handle at most")
> 
> I tried to disable the automatic flush (see http://kea.isc.org/ticket/3752 about that), which resulted in improved results.
> 
> Then I tried to bypass log4cplus completely (using a fstream with flush disabled).
> In this case the results are much better.
> 
> So I guess the convenience of logc4plus comes at a (big) cost for large volumes of logs.

Yes, there is an overhead in using the logging framework.

In your particular case, with the logging of every packet, are you doing
format conversions (e.g. converting a 32-bit IP address to
dotted-decimal format) before writing to disk?  If so, I'm wondering
whether writing the messages in a binary format (and viewing the log
off-line using a custom-written program) would give you a significant
increase in performance.

> Maybe there are parameters (besides the automatic flush) that can be tuned to improve performance ?

I've located this article:

http://stackoverflow.com/questions/7338439/is-log4cplus-really-so-slow

Admittedly it is somewhat old (2011), but the comments on that page
suggest that it is the FileAppender backend that is the bottleneck,
possibly due to the use of C++ streams to write the output.  It suggests
that tuning the log4cplus buffer size (which at present will have to be
done by modifying the code) may improve performance.

Stephen



More information about the kea-dev mailing list