When I finish performance testing I will add graphs to the Performance section of the gc-free manual page so that users can make an informed decision. (The below one is an example.)
So far, it seems that even with the garbage-free logging enabled, synchronous logging throughput (the green line) is usually slightly faster than it was with 2.5 (the purple line). So I think making garbage-free the default is acceptable. Also, users who care about logging throughput will be logging asynchronously, not synchronously: this scales much better with the number of application threads. On Mon, Apr 18, 2016 at 9:57 PM, Mikael Ståldal <mikael.stal...@magine.com> wrote: > Is it wise to enable by default given that "multi-threaded applications > that use synchronous logging may see worse performance"? > > On Mon, Apr 18, 2016 at 2:22 PM, Remko Popma <remko.po...@gmail.com> > wrote: > >> Enabled, except for web apps; for those log4j will be low garbage. >> >> See the first paragraph of the Configuration section in the manual page. >> >> Please let me know if this is not clear. (The fact that you asked means >> this probably needs improvement...) >> >> Sent from my iPhone >> >> On 2016/04/18, at 20:18, Mikael Ståldal <mikael.stal...@magine.com> >> wrote: >> >> Will garbage-free logging be enabled or disabled by default? >> >> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) <j...@apache.org> >> wrote: >> >>> >>> [ >>> https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018 >>> ] >>> >>> Remko Popma commented on LOG4J2-1297: >>> ------------------------------------- >>> >>> TODO allocate many temporary objects -> allocate temporary objects >>> >>> TODO multi-threaded applications that use synchronous logging may see >>> worse performance: the lock that was previously only around the IO >>> operation is widened to include the text formatting and conversion to >>> bytes. -> _synchronous_ logging performance may be worse for multi-threaded >>> applications in this mode due to synchronization on the shared buffer. If >>> your application is multi-threaded and logging performance is important, >>> consider using Async Loggers. >>> >>> TODO Caution: Only dates in the predefined formats are garbage-free -> >>> Caution: Only the predefined date formats are garbage-free >>> >>> TODO "(Note that Log4j may call toString() on message and parameter >>> objects when garbage-free logging is disabled because system property >>> log4j2.enable.threadlocals is set to "false".)" -> Log4j may call >>> toString() on message and parameter objects when garbage-free logging is >>> disabled (when system property log4j2.enable.threadlocals is set to >>> "false".) >>> >>> TODO "made an effort to make logging code garbage-free" -> "made an >>> effort to make logging garbage-free" >>> >>> >>> > 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: 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 >>> >>> >> >> >> -- >> [image: MagineTV] >> >> *Mikael Ståldal* >> Senior software developer >> >> *Magine TV* >> mikael.stal...@magine.com >> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >> >> Privileged and/or Confidential Information may be contained in this >> message. If you are not the addressee indicated in this message >> (or responsible for delivery of the message to such a person), you may >> not copy or deliver this message to anyone. In such case, >> you should destroy this message and kindly notify the sender by reply >> email. >> >> > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. >
