qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: Proposed qpid logging API
Date Wed, 09 May 2007 15:03:36 GMT
Just a shame we can't use the same in the Java Broker, would have been
good to have shared configuration files so we could get similar
logging from both brokers with a single configuration.

On 09/05/07, Alan Conway <aconway@redhat.com> wrote:
> 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
> configure.
> Cheers,
> Alan.

Martin Ritchie

View raw message