logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominik Psenner (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4NET-429) Pattern with Context property causes severe slowdown
Date Tue, 25 Mar 2014 12:31:20 GMT

    [ https://issues.apache.org/jira/browse/LOG4NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946453#comment-13946453
] 

Dominik Psenner edited comment on LOG4NET-429 at 3/25/14 12:31 PM:
-------------------------------------------------------------------

So far I came up with 3 solutions and let's discuss about those:

1] revert LOG4NET-205 and add a UserNameFilter and a IdentityFilter instead
2] add a global configuration flag that allows log4net to decide whether it should populate
the UserName and the Identity into the event properties dictionary
3] hack the properties dictionary to treat the UserNameProperty and the IdentityProperty specially,
allowing them to be looked up and cached only when they are requested

With 1 we solve the issue for good but we also drop a feature that has been introduced with
1.2.11 and thus we break backwards compatibilty. With 2 we allow people to work around the
issue when they are concerned about performance but do not solve the issue for real. 3 will
be the solution with no impact on the public API, but introduces a dirty hack.

>From my point of view we should aim towards solution 3 and thus I'm attaching a working
patch that suffers from the performance penalty only if somebody effectively uses _%property\{log4net:UserName}_
in the pattern layout.


was (Author: nachbarslumpi):
So far I came up with 3 solutions and let's discuss about those:

1] revert LOG4NET-205 and add a UserNameFilter and a IdentityFilter instead
2] add a global configuration flag that allows log4net to decide whether it should populate
the UserName and the Identity into the event properties dictionary
3] hack the properties dictionary to treat the UserNameProperty and the IdentityProperty specially,
allowing them to be looked up and cached only when they are requested

With 1 we solve the issue for good but we also drop a feature that has been introduced with
1.2.13 and thus we break backwards compatibilty. With 2 we allow people to work around the
issue when they are concerned about performance but do not solve the issue for real. 3 will
be the solution with no impact on the public API, but introduces a dirty hack.

>From my point of view we should aim towards solution 3 and thus I'm attaching a working
patch that suffers from the performance penalty only if somebody effectively uses _%property\{log4net:UserName}_
in the pattern layout.

> Pattern with Context property causes severe slowdown
> ----------------------------------------------------
>
>                 Key: LOG4NET-429
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-429
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.13
>            Reporter: Jonas Versén
>            Assignee: Dominik Psenner
>            Priority: Minor
>              Labels: performance
>         Attachments: LOG4NET-429.patch
>
>
> If you use a context property in your appenders pattern, there will be a significant
logging slowdown. In my experience anywhere from 3 to 5 times slower (this will depend on
the appender).
> I believe that as soon as you use a context property log4net will internally access the
windows user name even though it's not the property you want to access. This theory comes
from the fact that printing all properties in the pattern (including the costly property username)
compared to just printing one will slow down the logging with the same factor.
> I've made a stackoverflow question with more details as well
> http://stackoverflow.com/questions/22612286/using-log4net-context-properties-has-negative-impact-on-performance/



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message