logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Vincent.Bourdar...@nokia.com>
Subject RE: High performance filters
Date Wed, 19 Jul 2006 15:38:54 GMT
That's an interresting work arround.
Still that is tedious when several criterias are needed.

Since we are talking about a server, that would create a huge number of loggers. Do you have
any idea about performance impact?

>-----Original Message-----
>From: ext James Stauffer [mailto:stauffer.james@gmail.com] 
>Sent: Wednesday, July 19, 2006 5:22 PM
>To: Log4J Users List
>Subject: Re: High performance filters
>
>One option would be to include to the IP address in the logger name.
>Logger log = Logger.getLogger(getClass().getName() + "." + 
>request.getSourceAddress());
>
>That would create many more loggers but would allow
>log.isDebugEnabled() to work correctly.
>
>On 7/19/06, Vincent.Bourdaraud@nokia.com 
><Vincent.Bourdaraud@nokia.com> wrote:
>> I'm not sure your proposal solves my problem.
>> I'm sorry if my question was not clear enough. Let me try 
>another way:
>>
>> Considering the following code snippet
>>
>> // the following method is called-back hundred of time // per second.
>> public void process(Request request, Response response) {
>>     NDC.push("source-ip=" + request.getSourceAddress());
>>     if (log.isDebugEnabled())
>>     {
>>         log.debug(buildDebugMessage(request));
>>     }
>>     // process request and send response ...
>>     NDCP.pop();
>> }
>>
>> I need that log.debug(buildDebugMessage(request)) is called 
>only if the logger is in debug mode AND the source-ip within 
>the NDC is 192.168.0.12 (this source cause some trouble to the 
>server in this example), so that it would be possible to turn 
>live servers in debug mode for some (problematic) context and 
>investigate directly in production without killing performances.
>>
>> The NDC+Filtering method does not help that much here. It 
>does prevent messages from beeing wrote if they don't match 
>the expected context (source IP 192.168.0.12 in my example), 
>but it does not prevent the debug message from being built 
>(the buildDebugMessage(request) call) which is still quite 
>expensive (and useless in this context).
>>
>> I hope this is clear enough :)
>>
>> Thanks a lot for your time!
>> Vincent.
>>
>>
>>
>>
>> >-----Original Message-----
>> >From: ext Javier Gonzalez [mailto:jagonzal@gmail.com]
>> >Sent: Wednesday, July 19, 2006 3:44 PM
>> >To: Log4J Users List
>> >Subject: Re: High performance filters
>> >
>> >Create separate Loggers for the debug requests, and leave 
>only those 
>> >loggers at debug level. Then prepend log.debug() calls with 
>> >if(log.isDebugEnabled()), so that the debug messages will only be 
>> >created if the particular logger is debug enabled.
>> >
>> >(I'm not sure I understood your question correctly, though)
>> >
>> >On 7/19/06, Vincent.Bourdaraud@nokia.com 
>> ><Vincent.Bourdaraud@nokia.com> wrote:
>> >> Hi all,
>> >>
>> >> I'm building some kind of server and I use log4j for logging.
>> >> For troubleshooting issue I whant to be able to debug some few 
>> >> requests only (based on matching criterias) so that it is
>> >possible to
>> >> debug live servers without killing performances.
>> >>
>> >> I managed to use NDC and filters to do that and it does
>> >well. However,
>> >> filters are actually applied *after* log messages. Then using
>> >> NDC+filters solves only half the issue since the debug 
>messages are
>> >> still created (even if not logged to disk). And because this
>> >is quite
>> >> CPU and RAM intensive it would drop the performances below
>> >acceptable
>> >> production-level.
>> >>
>> >> Do you know if there is any way to use a filter-like mechanis at
>> >> log.isDebugEnabled() level for example? This way it would be
>> >possible
>> >> to not even build debug messages when the NDC does not match 
>> >> criterias, thus saving a lot CPU and RAM usage and allowing
>> >debugging live servers.
>> >>
>> >> Thanks all,
>> >> Vincent Bourdaraud.
>> >>
>> >>
>> >
>> >
>> >--
>> >Javier González Nicolini
>> >
>> 
>>---------------------------------------------------------------------
>> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> >For additional commands, e-mail: log4j-user-help@logging.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
>
>--
>James Stauffer
>Are you good? Take the test at http://www.livingwaters.com/good/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message