Would an embedded Tomcat/Jetty a la Spring Boot really be considered a web application?
On 18 April 2016 at 08:56, Remko Popma <remko.po...@gmail.com> wrote: > 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. >> > > -- Matt Sicker <boa...@gmail.com>
