Hi Denis Added as commit 025d7f6ac197fc8ca92c776b14d9205d6b899168 - I'll release as soon as I get the time (:
-d On 2022-02-22 12:36:47, Denis Petker <denis.pet...@rohde-schwarz.com> wrote: Hi Davyd, your patch looks good to me. It resolves my issue. Would be great if it could go into the next release. Many thanks, Denis -- Denis Petker Next Generation Solutions | 8BM3 Rohde & Schwarz GmbH & Co. KG Hanomaghof 1 | 30449 Hanover Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200 Internet: www.rohde-schwarz.com ------------------------------------------------------------ Geschäftsführung / Executive Board: Christian Leicher (Vorsitzender / Chairman), Peter Riedel, Sitz der Gesellschaft / Company's Place of Business: München, Registereintrag / Commercial Register No.: HRA 16 270, Persönlich haftender Gesellschafter / Personally Liable Partner: RUSEG Verwaltungs-GmbH, Sitz der Gesellschaft / Company's Place of Business: München, Registereintrag / Commercial Register No.: HRB 7 534, Umsatzsteuer-Identifikationsnummer (USt-IdNr.) / VAT Identification No.: DE 130 256 683, Elektro-Altgeräte Register (EAR) / WEEE Register No.: DE 240 437 86 From: Davyd McColl Sent: Tuesday, February 22, 2022 10:22 AM To: dev@logging.apache.org Cc: Petker Denis 8BM3 Subject: *EXT* [Newsletter] RE: [Newsletter] Re: log4net - performance hit because UserName is fetched always Hi Denis I would imagine that the use case is for shared logging config between processes. I think that the issue could be resolved by some caching in LoggingEvent.TryGetCurrentUserName (LoggingEvent.cs:927). I was just going to provide guidance, but it's probably quicker to just patch and test (: If you have the time, could you test the attached patch? Thanks -d On 2022-02-22 10:56:24, Denis Petker <>> wrote: Hi Davyd Thanks for the quick response! Agreed, I also don't think, that the username doesn't change for a process. If we say, that the username isn't going to change for a process, I think there is no reason in printing the user name per log statement. However, the ticket LOG4NET-205 has been raised by someone, who obviously was interested in filtering log events by username? So what you mean technically is to retrieve the username once at startup and cache for the remaining runtime? In order to be backward compatible, we then still need to maintain the UserName property in the LoggingEvent class I guess. So the username would then be provided to LoggingEvent objects from whatever is creating them? -----Original Message----- From: Davyd McColl Sent: Monday, February 21, 2022 6:43 PM To: dev@logging.apache.org; Petker Denis 8BM3 Subject: *EXT* [Newsletter] Re: log4net - performance hit because UserName is fetched always Hi Denis Thanks for the report (: I'm happy to review contributions, though for this particular issue, it seems like the resolution is to cache the resolved user name, rather than allowing specifying the name via config. The whole point of this property is to log the username under which the process is run (: The username for a process isn't going to change (at least, I'm not aware of a process for doing so), so it feels like the correct approach is simply to cache. Please feel free to raise a PR at github. I recognise that I'm not the fastest responder - there's just one of me and it seems like there's always something vying for my attention - but I do try to respond to pull requests as quickly as possible. I have another fix in the works for xml layouts anyway, though I was pursuing that with respect to another reported issue, but I could let that issue go for now for a hastier release. -d On Feb 21 2022, at 7:22 pm, Denis Petker wrote: > > Hi all, > > we have upgraded the log4net version from 1.2.10 to the newest version 2.0.14 > and are now facing performace issues. I already have done some investigation > looking at the log4net code. > With the ticket LOG4NET-205 > (https://issues.apache.org/jira/browse/LOG4NET-205) a change has been > introduced, which makes log4net not acceptable for us in terms of > performance. (Commit 5c023f6a22bfb93873a5ce0d6f5ac7e7275e2914) The change has > been done in order to be able to use UserName and Identity in the > PropertyFilter. It adds 'internal' properties representing the UserName and > Identity to the m_compositeProperties so that they are now accessible in the > PropertyFilter. That works as intended so far. See the attached diff > illustrating the change. > > The problem is, that fetching the UserName from the system is pretty > expensive. With the change above UserName is fetched always, regardless of > whether we use UserName or not. I did some benchmarking and this change > slowed down logging by a factor of 60. I also don’t see any way to get around > this by changing the configuration. I believe this can only be fixed by > changing code. > > I would suggest, rather than adding 'internal' properties to > m_compositeProperties, we should make the function > LoggingEvent.LookupProperty to look after the native properties, when > corresponding keys are specified. E.g. when the key "UserName" is specified, > we could return the value of the property LoggingEvent.UserName etc. > > In the meantime we want to use a changed version of log4net for our purposes. > I wonder, whether this change could be integrated into the official version? > I’ve never contributed to a public github project before, so don’t know how > to proceed really. > > Thanks, > Denis > > > This is the historic change causing the problem. > > > -- > Denis Petker > Next Generation Solutions | 8BM3 > > > > Rohde & Schwarz GmbH & Co. KG > Hanomaghof 1 | 30449 Hanover > Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200 > Internet: www.rohde-schwarz.com (http://www.rohde-schwarz.com/) > > ------------------------------------------------------------ > Geschäftsführung / Executive Board: Christian Leicher (Vorsitzender / > Chairman), Peter Riedel, Sitz der Gesellschaft / Company's Place of Business: > München, Registereintrag / Commercial Register No.: HRA 16 270, Persönlich > haftender Gesellschafter / Personally Liable Partner: RUSEG Verwaltungs-GmbH, > Sitz der Gesellschaft / Company's Place of Business: München, Registereintrag > / Commercial Register No.: HRB 7 534, Umsatzsteuer-Identifikationsnummer > (USt-IdNr.) / VAT Identification No.: DE 130 256 683, Elektro-Altgeräte > Register (EAR) / WEEE Register No.: DE 240 437 86 > >
