logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Garbage-free Log4j docs preview
Date Wed, 18 May 2016 23:34:42 GMT
Benedict, thanks for your feedback!

With regards to filtering, global filters are already considered before the 
event is enqueued. Filters configured on the Logger and AppenderRef are 
applied prior to enqueueing with mixed Sync/Async 
<http://logging.apache.org/log4j/2.x/manual/async.html#MixedSync-Async> 
Loggers but when all loggers are async 
<http://logging.apache.org/log4j/2.x/manual/async.html#AllAsync> these 
filters are applied by the background thread. We can probably improve this, 
thanks for the suggestion!

Your suggestion to run performance tests under lower loads is reasonable 
and we will look at this for a future release.
I did experiment with this a little a while back and did see larger 
response time pauses. Perhaps others with more experience can chime in.

My understanding of how the Disruptor works is that enqueueing the event is 
lock-free, so applications threads doing the logging should not experience 
any context switches or suffer latency from Futex calls caused by logging 
(regardless of the workload). The background thread is another story. Under 
moderate to low workloads the background thread may (depending on the wait 
policy) fall asleep and experience delays before waking up when work 
arrives. However, if there are enough cores to serve all threads I don't 
see how such background thread delays can impact (cause response time 
pauses for) the application that is doing the logging. Please correct me if 
my understanding is incorrect.

My thinking is that using async loggers is good for reactive applications 
that need to respond quickly to external events. It is especially useful if 
the application needs to deal with occasional bursts of work (and 
accompanied bursts of logging). This is where async loggers can deliver 
value even if the normal workload is low.

Remko

On Wednesday, May 18, 2016 at 2:56:18 AM UTC+9, Benedict Elliott Smith 
wrote:
>
> Regrettably it seems impossible (or at least very annoying) to send to 
> both lists simultaneously...
>
> On 17 May 2016 at 18:55, Benedict Elliott Smith <bene...@apache.org 
> <javascript:>> wrote:
>
>> Could I suggest that you run tests for latency and throughput effects of 
>> using this in systems with only moderate-to-low numbers of logging calls? 
>>  (i.e. the vast majority of systems!)
>>
>
>> It's very likely that in such systems messages will not reach a velocity 
>> to keep the Dispatcher running, and so logging calls may often (or always) 
>> involve a Futex call - which is not a trivial cost.  There will almost 
>> certainly be systems out there with anti-ideal characteristics - logging 
>> just often enough that these costs materially impact throughput, but not 
>> often enough that they suddenly disappear.  
>>
>> Even though a majority of systems *do not need this*, because it "async" 
>> and the new hotness, and there are no advertised downsides, everyone will 
>> try to use it.  It's up to those who know better to make sure these people 
>> are informed it isn't a free lunch.  Making sure all of the caveats are 
>> reported on the advertising page would be a great start IMO.
>>
>> Might I also separately suggest you consider filtering events prior to 
>> placing them on the queue for processing by the dispatcher?  I've only 
>> briefly glanced at the code, but it seems not to be the case currently.
>>
>>>
>>> On 17 May 2016 at 18:33, Martin Thompson <mjp...@gmail.com <javascript:>
>>> > wrote:
>>>
>>>> Hi Remko,
>>>>
>>>> I'd just like to say that it is a great service to the community as a 
>>>> whole that someone is seriously looking at improving logging.
>>>>
>>>> If you keep it up you'll be putting folks like me out of a job :)
>>>>
>>>> Martin...
>>>>
>>>>
>>>> On 17 May 2016 at 18:13, Remko Popma <remko...@gmail.com <javascript:>>

>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> First, my thanks to the many people who gave helpful advice and 
>>>>> feedback on how to measure Log4j response time on this list some time
ago.
>>>>>
>>>>> We're about to start the Log4j 2.6 release.
>>>>> If anyone is interested, a preview of the garbage-free logging manual

>>>>> page is here: 
>>>>> http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html
>>>>> and a preview of the updated performance page is here: 
>>>>> http://home.apache.org/~rpopma/log4j/2.6/performance.html
>>>>>
>>>>> Feedback welcome!
>>>>>
>>>>> Remko
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "mechanical-sympathy" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>>> an email to mechanical-sympathy+unsubscribe@googlegroups.com 
>>>>> <javascript:>.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "mechanical-sympathy" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to mechanical-sympathy+unsubscribe@googlegroups.com 
>>>> <javascript:>.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>
>
Mime
View raw message