[
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)
