[
https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255509#comment-15255509
]
Remko Popma commented on LOG4J2-1297:
-------------------------------------
Thoughts on which graphs to show in the performance section:
*Throughput*
I'm thinking to have two throughput graphs: one for synchronous and one for
asynchronous logging. I would like to compare the following setups at different
thread counts (1, 2, 4, 8, 16, 32 and 64):
* log4j-2.6 garbage-free
* log4j-2.6 classic
* log4j-2.5
* log4j-1.2.17
* logback-1.1.7
* JUL (Java 8)
Considerations:
- Which Appender? Just pick the fastest: RandomAccessFileAppender.
- We have 3 mechanisms for async logging. Again, just pick the fastest: all
loggers async.
*Response Time*
This is trickier because response time is a distribution and [cannot be
expressed in a single
number|http://www.infoq.com/presentations/latency-response-time].
Complicating factors for the response time test:
As Gil indicated in his original [DOs and
DONTs|https://groups.google.com/d/msg/mechanical-sympathy/0gaBXxFm4hE/O9QomwHIJAAJ]
and his [answer to my
question|https://groups.google.com/d/msg/mechanical-sympathy/HwTrOMnm6h0/wXchl1zMJwAJ]:
* a different number of threads constitutes a different setup, just like a
different logging library/version constitutes a different setup
* it is important to test at multiple loads
* use the same load when comparing latency behaviour of different setups
This makes for very busy graphs very soon. Perhaps it makes sense to break this
down into smaller pieces.
* Async: Compare the latency behaviour of garbage-free log4j 2.6 to classic 2.6
across a range of loads. TBD: what thread count?
* Async: Pick some thread count and compare four different loggers (JUL,
Logback, Log4j1, Log4j-2.6 garbage-free) at one or two different loads.
* Sync: Pick some thread count and compare four different loggers (JUL,
Logback, Log4j1, Log4j-2.6 garbage-free) at one or two different loads. (If
possible the same load as for the async test.)
> Document "gc-free" configuration and performance
> ------------------------------------------------
>
> Key: LOG4J2-1297
> URL: https://issues.apache.org/jira/browse/LOG4J2-1297
> Project: Log4j 2
> Issue Type: New Feature
> Components: Documentation
> Affects Versions: 2.5
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.6
>
> Attachments: LatencyHistogram.png, log4j-2.5-FlightRecording.png,
> log4j-2.6-FlightRecording.png
>
>
> Update the site with a description of which configurations are GC-free (i.e.,
> that don't create temporary objects in steady running state).
> Currently that means
> * Loggers are all asynchronous (Log4jContextSelector is set to
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
> * The configuration does not contain a <Properties> section.
> * The "steady-state" appenders are either RandomAccessFile or
> RollingRandomAccessFile Appenders (logging to any other appender will cause
> temporary objects to be created - including ConsoleAppender).
> * The Layout is a PatternLayout that uses one of the pre-defined date
> formats, does not have any regular expression replacements, and does not have
> lookups (TODO: may need to restrict this further).
> * The thread name is cached (this is the
> [default|https://issues.apache.org/jira/browse/LOG4J2-467]). Running with
> -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
> * In user code, when logging a parameterized message, the number of
> parameters is no more than ... (TBD pending discussion in LOG4J2-1278).
> * In user code, when logging a parameterized message, parameters of primitive
> type are boxed in a reused StringBuilder (Log4j provides a utility to make
> this relatively painless).
> Even with the above restrictions, Log4j may occasionally create garbage:
> * Initially StringBuilders are presized to 128 characters. They may grow for
> larger messages (contributing to garbage in Old Gen). If the StringBuilder
> grows beyond 512 characters it is trimmed back to 512 characters to prevent
> memory leaks from excessively long messages. (TODO: the resizing algorithm is
> {{size = value.length * 2 + 2}}, so a better cutoff value is 518.)
> * Messages containing {{"$\{"}} will be converted to a String and
> StrSubstitutor will be used to replace occurences of variables with their
> matching values. Multiple temporary objects are created during this process.
> Furthermore, we need to explain that some of this functionality depends on
> ThreadLocals and so is disabled by default in web applications to prevent
> memory leaks. The page should also explain how to manually switch off the use
> of ThreadLocals.
> Finally, the page should show a performance test comparison similar to the
> [performance
> section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on
> the Async Loggers page. I'm thinking a comparison between Logback, Log4j-1,
> Log4j-2.0, Log4j-2.6 "classic" and Log4j-2.6 "gc-free" would be ideal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
