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