I’m open to improvements in this area. Before going into details or specifics though, I’m curious:
What do we (users, developers and PMC members) consider to be the “value proposition” of Log4j? Why should people choose Log4j over the alternatives? This is a positioning question; what are the strengths and weaknesses of Log4j and how should Log4j position itself in the market of logging solutions? Remko > On Jan 15, 2024, at 22:05, Gary Gregory <garydgreg...@gmail.com> wrote: > > We should IMO keep this information available _somewhere_, maybe in a new > stable historical-archival section of the site. I'm not a fan of using the > wiki because that's yet another place to look for information and it feels > transitory, unstable (as far as information permanance), and more like > something we should use (if at all) as a scratch pad. > > Gary > >> On Mon, Jan 15, 2024, 7:34 AM Volkan Yazıcı <vol...@yazi.ci> wrote: >> >> *TLDR:* I want to remove performance figures from the Log4j website, >> because they don't serve any practical value anymore. >> >> Log4j website shares performance figures in several pages; Performance >> <https://logging.apache.org/log4j/2.x/performance.html#benchmarks>, >> Asynchronous >> Logging >> < >> https://logging.apache.org/log4j/2.x/manual/async.html#asynchronous-logging-performance >>> , >> Garbage-free Logging >> <https://logging.apache.org/log4j/2.x/manual/garbagefree.html> are among >> the well-known ones. I want to remove all performance figures and only keep >> pragmatic recommendations due to following reasons: >> >> - *Insufficient relevancy* – Shared figures were mostly produced using >> Log4j version `2.5` and `2.6`. These releases date back from late 2016 >> and >> *a lot* has changed since then. >> - *Insufficient reliability* – There were many occasions PMC members >> stated they weren't able to reproduce these figures. >> - *Error prone* – As tipped in the website, measuring performance >> correctly is very difficult >> <https://www.infoq.com/presentations/latency-response-time>. >> - *Context dependent* – Performance is an extremely subjective term. It >> requires context. What kind of an application? What is the application >> load? What is the logging load? What is the logging setup? etc. Sharing >> a >> meaningful figure here that users can benefit in any way is, IMHO, >> impossible. >> - *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt if >> any of the existing performance figures (produced using ~8 year old >> Log4j) >> are applicable to Log4j 3. >> >> Will we have no performance figures at all? AFAIC, we need to have a >> continuous performance testbed that would not only give users an indication >> about performance of Log4j over time (in a reproducible way!), but also, >> maybe more importantly, guide maintainers on making changes affecting >> performance. Some of you might recall: I already had implemented some stuff >> on this subject and had a "a continuous performance testbed" project in my >> first STF projects draft. But we needed to drop it due to other pressing >> issues and insufficient budget. We can bring it up again if need (and >> budget?) arises. Let me know if you and/or your employer would be >> interested in funding such an effort. >>
