qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Proposed qpid logging API
Date Wed, 09 May 2007 13:27:36 GMT
On Wed, 2007-05-09 at 07:53 -0400, Kim van der Riet wrote:
> Two silly questions:
Quite pertinent actually!

> 1. What are the performance constraints on the logging infrastructure?
> Clearly, any logging activity that occurs in performance-critical
> sections of the code need to be closely looked at... Do we have a
> strategy for evaluating this for any proposed solution? 

My main criteria for now is near-zero overhead for disabled log
statements so we can reasonably leave logging in production code. rlog
is the best of the bunch in that regard, and probably at the theoretical
limit short of actually compiling them out: a single if (ptr!=0) (with
extra optimization hints for g++) - ends up about 3 machine instructions
on x86 for disabled logs.

The other dimension is performance when logging is enabled, which
determines how much logging you can usefully turn on before things slow
to the point of uselessness. Pantheios is the winner here:
http://pantheios.sourceforge.net/performance.html but as the graphs show
the differences with logging enabled are not nearly as dramatic as the
logging off differences. The proposed QPID API will perform like the
IOStream column in those tests. The native rlog printf API would be
about the same (like logprintf in the graph).

Rationale for the API:
 - Macro API is most flexible and easiest to wrap around other APIs.
 - Ostream formatting is type safe
 - Most "stringable" C++ types have ostream<< operators
 - boost::format provides printf formatting compatible with ostream.

Rationale for rlog:
 - fastest in no-logging case
 - small but flexible and covers basics
 - I estimate will be quickest for me to implement in Qpid.

Rlog is not "the" qpid logging framework, its just the first impl. I'll
do a brain-dead homegrown alternative to satisfy Apache licensing. We
can replace with another alterantive if/when we feel the need.

> 2. Are there any reliability/write guarantees on logging, in other
> words, when some of the logging is sent to disk, is there any
> requirement that it must arrive there before continuing, or is it not an
> issue?

Assume there are no guarantees at all. Logging (in this sense of the
overloaded word) is for debug/management purposes. It's best effort but
it should not take measures to be reliable that would slow the app down.

Actual guarantees depend on how back-end is implemented, which I think
is regular buffered file writes or syslog calls depending on how you


View raw message