Uploaded image for project: 'Log4net'
  1. Log4net
  2. LOG4NET-421

Inclusion of UserName in composite properties dictionary has a significant performance impact

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: 1.2.13
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
    • Environment:
      Issue was observed on Windows Server 2008 R2 with an ASP.NET 4.0 application.

      Description

      A change made for LOG4NET-205 has the LoggingEvent.CreateCompositeProperties method get the UserName property for every log event. Since getting the UserName is very slow, this change has a significant impact on performance in log4net.

      In one trace captured with dotTrace on a large web application we found that the get UserName property (called from CreateCompositeProperties) accounted for 34% of all time spent in log4net code.

      Our workaround for the issue has been to "fix" the UserName property by adding <fix value="32" /> to all our appenders.

        Issue Links

          Activity

          Hide
          tvoros Tom Voros added a comment -

          This issue may impact versions 1.2.11 and 1.2.12 as well. I couldn't find LOG4NET-205 in the release notes to confirm.

          Show
          tvoros Tom Voros added a comment - This issue may impact versions 1.2.11 and 1.2.12 as well. I couldn't find LOG4NET-205 in the release notes to confirm.
          Hide
          nachbarslumpi Dominik Psenner added a comment -

          This issue is a duplicate of LOG4NET-429.

          Show
          nachbarslumpi Dominik Psenner added a comment - This issue is a duplicate of LOG4NET-429 .
          Hide
          tvoros Tom Voros added a comment -

          Thank you for acknowledging the issue. I'm optimistic about the solution you've offered in LOG4NET-429.

          I can't seem to edit the description above but I wanted to clarify that the "fix" workaround will not work in all cases. Only certain appender types support the <fix ... /> option and unfortunately RollingFileAppender (the most common appender type?) is not one of them.

          Show
          tvoros Tom Voros added a comment - Thank you for acknowledging the issue. I'm optimistic about the solution you've offered in LOG4NET-429 . I can't seem to edit the description above but I wanted to clarify that the "fix" workaround will not work in all cases. Only certain appender types support the <fix ... /> option and unfortunately RollingFileAppender (the most common appender type?) is not one of them.

            People

            • Assignee:
              nachbarslumpi Dominik Psenner
              Reporter:
              tvoros Tom Voros
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development