Sorry if will be saying dumb things here, as I've seen that several years ago and have no time to review that now; but maybe that'll ring the bell for somebody
I thought that UserName could be related to user name from principal (thus basically anything set in code - and can be easily different for the same thread in say asp.net environment), not the windows user name of the process Thanks, Vladimir On Tue, 22 Feb 2022 at 14:26, Dominik Psenner <[email protected]> wrote: > 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 <[email protected] > > > 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 <[email protected]> > > Sent: Monday, February 21, 2022 6:43 PM > > To: [email protected]; Petker Denis 8BM3 < > > [email protected]> > > 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 <[email protected] > > > > 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 >
