I believe the caching has already been implemented but don't have any references to mention right now.
On Tue, 22 Feb 2022 at 09:56, Denis Petker <denis.pet...@rohde-schwarz.com> 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 <dav...@gmail.com> > Sent: Monday, February 21, 2022 6:43 PM > To: dev@logging.apache.org; Petker Denis 8BM3 < > denis.pet...@rohde-schwarz.com> > 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 <denis.pet...@rohde-schwarz.com> > 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 > > > > > -- Dominik Psenner
