logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Questions about switching to async and other performance-related config
Date Tue, 07 Aug 2018 19:37:20 GMT
On 8/7/2018 11:13 AM, Remko Popma wrote:
> Async logging will not cause messages to appear out of order in the log file.

That's good to know.  I figured it would be at least theoretically
possible.  If for some reason processing one log message took slightly
longer than processing the next log message, the later log message might
end up getting logged first.  There might not be much danger of
radically different processing times for different log messages,
though.  Sounds like I really don't need to be worried about it.

> Please take a look at the performance page (https://logging.apache.org/log4j/2.x/performance.html).
Async logging is fast because of reduced lock contention. Lock contention happens when you
have many threads logging simultaneously. If your application doesn’t do that, benefits
will be limited.

As already discussed, Solr *can* do a lot of logging simultaneously. 
What I would think of as a "typical" install probably won't have
sustained periods of heavy logging.  It all depends on what kind of
traffic patterns the Solr install will be handling.

> The 10% speedup you mentioned indicates to me that logging is not the main performance
bottleneck (at least during the tests).

I would agree with that assessment.  Although 10 percent isn't
earth-shattering, it's *something*.  If there are any massive
performance improvements to be made, the problems will be found
elsewhere.  There have been a number of impressive performance gains
achieved by Lucene and Solr over the years, maybe there are a few more
still left to be found.

> It’s a nice gain for little effort, but if your aim is to dramatically improve the
performance of your application, it’s best to first approach this systematically: identify
the biggest bottleneck, optimize that, measure again, etc. 

I see it as an easy win - a tiny change with little danger that has the
potential to improve performance for all users.  Some users might see
big gains, but a lot of them probably won't even be able to measure the
difference.  I think it's an enhancement that can help Solr scale for
heavy loads, not something that will massively improve life for everyone.

Thank you for taking the time to discuss this.  It's been helpful.


To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message