logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: why is AsyncLoggerContextSelector faster?
Date Mon, 21 Jul 2014 14:22:01 GMT
Hi,
No that is incorrect.
If you do not specify AsyncLoggerContextSelector but instead configure with
<AsyncRoot> and <AsyncLogger> loggers, you _do_ need the disruptor jar on
the classpath and this does _not_ use AsyncAppender. AsyncAppender is
completely separate from Async Loggers. Async Loggers (mixed or all async)
use the disruptor and both need the disruptor jar.

You keep mentioning a performance difference. I was assuming you were
talking about the performance test results mentioned on the Async Logger
manual page, but perhaps I was wrong? Are you experiencing a performance
difference between the two flavors of Async Loggers in your application?




On Mon, Jul 21, 2014 at 11:10 PM, Mariano Gonzalez <
mariano.l.gonzalez@gmail.com> wrote:

> Hello Remko,
>
> I think I found the difference. AsyncLoggerContextSelector always returns
> the same instance of AsyncLoggerContext, which in turns always returns
> instances of AsyncLogger, which uses disruptor to handle concurrency.
>
> However, with any other selector, a standard Logger instance is returned
> and parallelism is achieved through an AsyncAppender. AsyncAppender use a
> standard blocking queue instead of using disruptor which explains the
> performance difference (there's also the fact that
> AsyncLoggerContextSelector always returns the same context instance and
> does not spend cycles in the lookup, but I think that is not a significant
> cost once everything was warmed out).
>
> http://logging.apache.org/log4j/2.x/manual/async.html says that when using
> mixed type loggers disruptor is needed on the classpath. That seems to be
> an error. For what I see disruptor is only used when setting all loggers
> asynchronous.
>
> Does this make sense? Anyway around this? Do you have a disruptor appender
> somewhere?
>
> Thanks!
>
>
> On Sat, Jul 19, 2014 at 11:55 PM, Remko Popma <remko.popma@gmail.com>
> wrote:
>
> > To be honest, I haven't investigated in detail the reason for the
> > difference in throughput in the performance test.
> >
> > Are you measuring the performance of your application container, and can
> > you see an improvement when using Async Loggers?
> > Do you see a large difference in performance _in your application_
> between
> > making all loggers Asynchronous and using mixed synchronous and
> > Asynchronous loggers?
> >
> >
> > On Sun, Jul 20, 2014 at 7:45 AM, Mariano Gonzalez <
> > mariano.l.gonzalez@gmail.com> wrote:
> >
> > > Hello Remko,
> > >
> > > Thanks for the insight. I guess my case falls into the wrong end of the
> > > pareto law. My project is a low latency application container, so I
> need
> > to
> > > have:
> > >
> > >
> > >    - low latency
> > >    - log separation (I actually had to implement my own context
> selector
> > >    because my logic is more complicated than the standard
> > >    ClassLoaderContextSelector case)
> > >    - I want async loggers by default, but deployed apps need to be able
> > to
> > >    specify sync loggers
> > >
> > >
> > > Right now I'm kinda meeting those requirements using config file,
> > AsyncRoot
> > > and my custom selector, but it'd be really great to achieve a
> performance
> > > level like the one that AsyncContextSelector promises.
> > >
> > > Is there a way of doing that? For what I see on the code, the
> > > AsyncLoggerContextSelector's secret sauce is just to always return an
> > > AsyncLogger on the newInstance() method. Why is that so much faster
> than
> > > what ClassLoaderLoggerContextSelector does?
> > >
> > > Thanks!
> > >
> > >
> > > On Fri, Jul 18, 2014 at 1:20 PM, Remko Popma <remko.popma@gmail.com>
> > > wrote:
> > >
> > > > The Async Loggers created with the context selector have a slightly
> > > > different mechanism. One of the differences is that LogEvent objects
> > are
> > > > re-used.
> > > >
> > > > However, unless your application is in the low-latency space, I would
> > not
> > > > worry too much about the performance difference. Both flavors of
> Async
> > > > Loggers are much faster than the alternative (Async Appenders).
> > > >
> > > > Your point is valid though. I've been thinking about an alternative
> way
> > > to
> > > > configure Async Loggers than via system properties. The work in
> > progress
> > > is
> > > > tracked in Jira ticket LOG4J2-321
> > > > <https://issues.apache.org/jira/browse/LOG4J2-321>. This is still
in
> > the
> > > > concept phase though. Meanwhile your best option is probably to use
> > > > ClassLoaderContextSelector and configure with <AsyncRoot> and
> > > > <AsyncLogger>.
> > > >
> > > >
> > > >
> > > > On Fri, Jul 18, 2014 at 10:57 PM, Mariano Gonzalez <
> > > > mariano.l.gonzalez@gmail.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > According to the performance charts in the documentation, log4j2
> has
> > a
> > > > > significantly higher throughput when using
> AsyncLoggerContextSelector
> > > > than
> > > > > when using all async loggers with any different selector.
> > > > >
> > > > > Why is that? Is it just because the same context is always reused
> and
> > > > > there's no lookup like in the ClassLoaderContextSelector case?
> > > > >
> > > > > If I need functionality similar to ClassLoaderContextSelector, is
> > there
> > > > any
> > > > > way to get a throughput similar to AsyncLoggerContextSelector?
> > > > >
> > > > > Thanks!
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message