[ 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: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org