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 <[EMAIL PROTECTED]> 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
