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