You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2018/10/22 21:40:22 UTC
GC Free Layouts
Hello,
I am working on the next release of log4j2-logstash-layout
<https://github.com/vy/log4j2-logstash-layout/tree/json-generator>, which
is an alternative to the default JsonLayout and allows custom JSON schemas.
There I achieved to get up to 5x speed up compared to JsonLayout[1] and I
want to stretch this further by reducing the GC load. Though it is really
difficult given Layout interface (practically) requires an output of type
String. I examined the internals of other gc-free layouts, e.g., Pattern,
Gelf, etc. Though each ends up making a call to StringBuilder#toString(),
which is not gc-free, to the best of my knowledge. Would anyone mind
shedding some light onto the issue, please?
Best.
[1] Please feel free to check JMH benchmarks
<https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java>
and their results
<https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt>.
Maybe there I am misconfiguring JsonLayout to cause it under-perform.
Re: GC Free Layouts
Posted by Matt Sicker <bo...@gmail.com>.
Aren’t lambdas garbage free? At least if you don’t close over any state
that is.
On Thu, Oct 25, 2018 at 17:07, Remko Popma <re...@gmail.com> wrote:
> A dirty alternative is to check with instanceof and cast to
> IndexedStringMap and use indexed access. But BiConsumer or TriConsumer are
> a lot cleaner.
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Oct 25, 2018, at 20:55, Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >
> > It is not really that easy in my case -- there are variables reached
> > outside of the scope. But ok, I will see what I can do about it. I
> > thought there might exist a utility class or sth like that to let me
> > access it like a List/Array.
> >
> > What about the ContextStack?
> >
> >> On Thu, Oct 25, 2018 at 10:19 AM Remko Popma <re...@gmail.com>
> wrote:
> >>
> >> You can keep a pre-allocated BiConsumer (or multiple ThreadLocal ones)
> to
> >> avoid allocating a new consumer for each event. (I think that’s what we
> do
> >> in Log4j.)
> >>
> >> Remko.
> >>
> >> (Shameless plug) Every java main() method deserves http://picocli.info
> >>
> >>> On Oct 25, 2018, at 15:50, Volkan Yazıcı <vo...@gmail.com>
> >> wrote:
> >>>
> >>> One thing I am still struggling is how to iterate over ContextData and
> >>> ContextStack without any garbage.
> >>> ContextData#forEach() necessitates instantiation of a new
> >>> BiConsumer<String, Object>.
> >>> And likewise, ContextStack necessitates instantiation of a new Iterator
> >> for
> >>> traversal.
> >>> Am I missing something? Is there any other way to traverse these
> >>> collections without generating garbage?
> >>>
> >>>> On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <re...@gmail.com>
> >> wrote:
> >>>>
> >>>> Looks very nice!
> >>>>
> >>>> The non garbage-free implementation is in the toSerializable(LogEvent)
> >>>> method. As you point out, this often ends in a call to
> >>>> StringBuilder.toString().
> >>>>
> >>>> The garbage-free implementation is in the encode(LogEvent,
> >>>> ByteBufferDestination) method. This reuses a ThreadLocal
> StringBuilder.
> >>>>
> >>>> Be aware of edge cases like occasional very large messages that result
> >> in
> >>>> the reusable StringBuilder taking up a lot of memory and never
> releasing
> >>>> it. (We trim if some configurable max size is exceeded.)
> >>>> You get some of this for free by extending AbstractStringLayout.
> >>>>
> >>>> I took a brief look at the BENCHMARK.txt file but didn’t have time to
> >> look
> >>>> in detail. A graph comparison would be very cool!
> >>>>
> >>>> Good luck, keep us posted!
> >>>>
> >>>> (Shameless plug) Every java main() method deserves
> http://picocli.info
> >>>>
> >>>>> On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com>
> >> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> I am working on the next release of log4j2-logstash-layout
> >>>>> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>,
> >>>> which
> >>>>> is an alternative to the default JsonLayout and allows custom JSON
> >>>> schemas.
> >>>>> There I achieved to get up to 5x speed up compared to JsonLayout[1]
> >> and I
> >>>>> want to stretch this further by reducing the GC load. Though it is
> >> really
> >>>>> difficult given Layout interface (practically) requires an output of
> >> type
> >>>>> String. I examined the internals of other gc-free layouts, e.g.,
> >> Pattern,
> >>>>> Gelf, etc. Though each ends up making a call to
> >> StringBuilder#toString(),
> >>>>> which is not gc-free, to the best of my knowledge. Would anyone mind
> >>>>> shedding some light onto the issue, please?
> >>>>>
> >>>>> Best.
> >>>>>
> >>>>> [1] Please feel free to check JMH benchmarks
> >>>>> <
> >>>>
> >>
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java
> >>>>>
> >>>>> and their results
> >>>>> <
> >>>>
> >>
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt
> >>>>> .
> >>>>> Maybe there I am misconfiguring JsonLayout to cause it under-perform.
> >>>>
> >>
>
--
Matt Sicker <bo...@gmail.com>
Re: GC Free Layouts
Posted by Remko Popma <re...@gmail.com>.
A dirty alternative is to check with instanceof and cast to IndexedStringMap and use indexed access. But BiConsumer or TriConsumer are a lot cleaner.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Oct 25, 2018, at 20:55, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> It is not really that easy in my case -- there are variables reached
> outside of the scope. But ok, I will see what I can do about it. I
> thought there might exist a utility class or sth like that to let me
> access it like a List/Array.
>
> What about the ContextStack?
>
>> On Thu, Oct 25, 2018 at 10:19 AM Remko Popma <re...@gmail.com> wrote:
>>
>> You can keep a pre-allocated BiConsumer (or multiple ThreadLocal ones) to
>> avoid allocating a new consumer for each event. (I think that’s what we do
>> in Log4j.)
>>
>> Remko.
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>> On Oct 25, 2018, at 15:50, Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>>
>>> One thing I am still struggling is how to iterate over ContextData and
>>> ContextStack without any garbage.
>>> ContextData#forEach() necessitates instantiation of a new
>>> BiConsumer<String, Object>.
>>> And likewise, ContextStack necessitates instantiation of a new Iterator
>> for
>>> traversal.
>>> Am I missing something? Is there any other way to traverse these
>>> collections without generating garbage?
>>>
>>>> On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <re...@gmail.com>
>> wrote:
>>>>
>>>> Looks very nice!
>>>>
>>>> The non garbage-free implementation is in the toSerializable(LogEvent)
>>>> method. As you point out, this often ends in a call to
>>>> StringBuilder.toString().
>>>>
>>>> The garbage-free implementation is in the encode(LogEvent,
>>>> ByteBufferDestination) method. This reuses a ThreadLocal StringBuilder.
>>>>
>>>> Be aware of edge cases like occasional very large messages that result
>> in
>>>> the reusable StringBuilder taking up a lot of memory and never releasing
>>>> it. (We trim if some configurable max size is exceeded.)
>>>> You get some of this for free by extending AbstractStringLayout.
>>>>
>>>> I took a brief look at the BENCHMARK.txt file but didn’t have time to
>> look
>>>> in detail. A graph comparison would be very cool!
>>>>
>>>> Good luck, keep us posted!
>>>>
>>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>>
>>>>> On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I am working on the next release of log4j2-logstash-layout
>>>>> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>,
>>>> which
>>>>> is an alternative to the default JsonLayout and allows custom JSON
>>>> schemas.
>>>>> There I achieved to get up to 5x speed up compared to JsonLayout[1]
>> and I
>>>>> want to stretch this further by reducing the GC load. Though it is
>> really
>>>>> difficult given Layout interface (practically) requires an output of
>> type
>>>>> String. I examined the internals of other gc-free layouts, e.g.,
>> Pattern,
>>>>> Gelf, etc. Though each ends up making a call to
>> StringBuilder#toString(),
>>>>> which is not gc-free, to the best of my knowledge. Would anyone mind
>>>>> shedding some light onto the issue, please?
>>>>>
>>>>> Best.
>>>>>
>>>>> [1] Please feel free to check JMH benchmarks
>>>>> <
>>>>
>> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java
>>>>>
>>>>> and their results
>>>>> <
>>>>
>> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt
>>>>> .
>>>>> Maybe there I am misconfiguring JsonLayout to cause it under-perform.
>>>>
>>
Re: GC Free Layouts
Posted by Remko Popma <re...@gmail.com>.
I don’t think it’s possible to make use of the ContextStack in a GC-free way. But I’m away from my pc now and speaking from memory.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Oct 25, 2018, at 20:55, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> It is not really that easy in my case -- there are variables reached
> outside of the scope. But ok, I will see what I can do about it. I
> thought there might exist a utility class or sth like that to let me
> access it like a List/Array.
>
> What about the ContextStack?
>
>> On Thu, Oct 25, 2018 at 10:19 AM Remko Popma <re...@gmail.com> wrote:
>>
>> You can keep a pre-allocated BiConsumer (or multiple ThreadLocal ones) to
>> avoid allocating a new consumer for each event. (I think that’s what we do
>> in Log4j.)
>>
>> Remko.
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>> On Oct 25, 2018, at 15:50, Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>>
>>> One thing I am still struggling is how to iterate over ContextData and
>>> ContextStack without any garbage.
>>> ContextData#forEach() necessitates instantiation of a new
>>> BiConsumer<String, Object>.
>>> And likewise, ContextStack necessitates instantiation of a new Iterator
>> for
>>> traversal.
>>> Am I missing something? Is there any other way to traverse these
>>> collections without generating garbage?
>>>
>>>> On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <re...@gmail.com>
>> wrote:
>>>>
>>>> Looks very nice!
>>>>
>>>> The non garbage-free implementation is in the toSerializable(LogEvent)
>>>> method. As you point out, this often ends in a call to
>>>> StringBuilder.toString().
>>>>
>>>> The garbage-free implementation is in the encode(LogEvent,
>>>> ByteBufferDestination) method. This reuses a ThreadLocal StringBuilder.
>>>>
>>>> Be aware of edge cases like occasional very large messages that result
>> in
>>>> the reusable StringBuilder taking up a lot of memory and never releasing
>>>> it. (We trim if some configurable max size is exceeded.)
>>>> You get some of this for free by extending AbstractStringLayout.
>>>>
>>>> I took a brief look at the BENCHMARK.txt file but didn’t have time to
>> look
>>>> in detail. A graph comparison would be very cool!
>>>>
>>>> Good luck, keep us posted!
>>>>
>>>> (Shameless plug) Every java main() method deserves http://picocli.info
>>>>
>>>>> On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com>
>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I am working on the next release of log4j2-logstash-layout
>>>>> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>,
>>>> which
>>>>> is an alternative to the default JsonLayout and allows custom JSON
>>>> schemas.
>>>>> There I achieved to get up to 5x speed up compared to JsonLayout[1]
>> and I
>>>>> want to stretch this further by reducing the GC load. Though it is
>> really
>>>>> difficult given Layout interface (practically) requires an output of
>> type
>>>>> String. I examined the internals of other gc-free layouts, e.g.,
>> Pattern,
>>>>> Gelf, etc. Though each ends up making a call to
>> StringBuilder#toString(),
>>>>> which is not gc-free, to the best of my knowledge. Would anyone mind
>>>>> shedding some light onto the issue, please?
>>>>>
>>>>> Best.
>>>>>
>>>>> [1] Please feel free to check JMH benchmarks
>>>>> <
>>>>
>> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java
>>>>>
>>>>> and their results
>>>>> <
>>>>
>> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt
>>>>> .
>>>>> Maybe there I am misconfiguring JsonLayout to cause it under-perform.
>>>>
>>
Re: GC Free Layouts
Posted by Volkan Yazıcı <vo...@gmail.com>.
It is not really that easy in my case -- there are variables reached
outside of the scope. But ok, I will see what I can do about it. I
thought there might exist a utility class or sth like that to let me
access it like a List/Array.
What about the ContextStack?
On Thu, Oct 25, 2018 at 10:19 AM Remko Popma <re...@gmail.com> wrote:
> You can keep a pre-allocated BiConsumer (or multiple ThreadLocal ones) to
> avoid allocating a new consumer for each event. (I think that’s what we do
> in Log4j.)
>
> Remko.
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Oct 25, 2018, at 15:50, Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >
> > One thing I am still struggling is how to iterate over ContextData and
> > ContextStack without any garbage.
> > ContextData#forEach() necessitates instantiation of a new
> > BiConsumer<String, Object>.
> > And likewise, ContextStack necessitates instantiation of a new Iterator
> for
> > traversal.
> > Am I missing something? Is there any other way to traverse these
> > collections without generating garbage?
> >
> >> On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <re...@gmail.com>
> wrote:
> >>
> >> Looks very nice!
> >>
> >> The non garbage-free implementation is in the toSerializable(LogEvent)
> >> method. As you point out, this often ends in a call to
> >> StringBuilder.toString().
> >>
> >> The garbage-free implementation is in the encode(LogEvent,
> >> ByteBufferDestination) method. This reuses a ThreadLocal StringBuilder.
> >>
> >> Be aware of edge cases like occasional very large messages that result
> in
> >> the reusable StringBuilder taking up a lot of memory and never releasing
> >> it. (We trim if some configurable max size is exceeded.)
> >> You get some of this for free by extending AbstractStringLayout.
> >>
> >> I took a brief look at the BENCHMARK.txt file but didn’t have time to
> look
> >> in detail. A graph comparison would be very cool!
> >>
> >> Good luck, keep us posted!
> >>
> >> (Shameless plug) Every java main() method deserves http://picocli.info
> >>
> >>> On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com>
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am working on the next release of log4j2-logstash-layout
> >>> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>,
> >> which
> >>> is an alternative to the default JsonLayout and allows custom JSON
> >> schemas.
> >>> There I achieved to get up to 5x speed up compared to JsonLayout[1]
> and I
> >>> want to stretch this further by reducing the GC load. Though it is
> really
> >>> difficult given Layout interface (practically) requires an output of
> type
> >>> String. I examined the internals of other gc-free layouts, e.g.,
> Pattern,
> >>> Gelf, etc. Though each ends up making a call to
> StringBuilder#toString(),
> >>> which is not gc-free, to the best of my knowledge. Would anyone mind
> >>> shedding some light onto the issue, please?
> >>>
> >>> Best.
> >>>
> >>> [1] Please feel free to check JMH benchmarks
> >>> <
> >>
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java
> >>>
> >>> and their results
> >>> <
> >>
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt
> >>> .
> >>> Maybe there I am misconfiguring JsonLayout to cause it under-perform.
> >>
>
Re: GC Free Layouts
Posted by Remko Popma <re...@gmail.com>.
You can keep a pre-allocated BiConsumer (or multiple ThreadLocal ones) to avoid allocating a new consumer for each event. (I think that’s what we do in Log4j.)
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Oct 25, 2018, at 15:50, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> One thing I am still struggling is how to iterate over ContextData and
> ContextStack without any garbage.
> ContextData#forEach() necessitates instantiation of a new
> BiConsumer<String, Object>.
> And likewise, ContextStack necessitates instantiation of a new Iterator for
> traversal.
> Am I missing something? Is there any other way to traverse these
> collections without generating garbage?
>
>> On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <re...@gmail.com> wrote:
>>
>> Looks very nice!
>>
>> The non garbage-free implementation is in the toSerializable(LogEvent)
>> method. As you point out, this often ends in a call to
>> StringBuilder.toString().
>>
>> The garbage-free implementation is in the encode(LogEvent,
>> ByteBufferDestination) method. This reuses a ThreadLocal StringBuilder.
>>
>> Be aware of edge cases like occasional very large messages that result in
>> the reusable StringBuilder taking up a lot of memory and never releasing
>> it. (We trim if some configurable max size is exceeded.)
>> You get some of this for free by extending AbstractStringLayout.
>>
>> I took a brief look at the BENCHMARK.txt file but didn’t have time to look
>> in detail. A graph comparison would be very cool!
>>
>> Good luck, keep us posted!
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>> On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> I am working on the next release of log4j2-logstash-layout
>>> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>,
>> which
>>> is an alternative to the default JsonLayout and allows custom JSON
>> schemas.
>>> There I achieved to get up to 5x speed up compared to JsonLayout[1] and I
>>> want to stretch this further by reducing the GC load. Though it is really
>>> difficult given Layout interface (practically) requires an output of type
>>> String. I examined the internals of other gc-free layouts, e.g., Pattern,
>>> Gelf, etc. Though each ends up making a call to StringBuilder#toString(),
>>> which is not gc-free, to the best of my knowledge. Would anyone mind
>>> shedding some light onto the issue, please?
>>>
>>> Best.
>>>
>>> [1] Please feel free to check JMH benchmarks
>>> <
>> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java
>>>
>>> and their results
>>> <
>> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt
>>> .
>>> Maybe there I am misconfiguring JsonLayout to cause it under-perform.
>>
Re: GC Free Layouts
Posted by Volkan Yazıcı <vo...@gmail.com>.
One thing I am still struggling is how to iterate over ContextData and
ContextStack without any garbage.
ContextData#forEach() necessitates instantiation of a new
BiConsumer<String, Object>.
And likewise, ContextStack necessitates instantiation of a new Iterator for
traversal.
Am I missing something? Is there any other way to traverse these
collections without generating garbage?
On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <re...@gmail.com> wrote:
> Looks very nice!
>
> The non garbage-free implementation is in the toSerializable(LogEvent)
> method. As you point out, this often ends in a call to
> StringBuilder.toString().
>
> The garbage-free implementation is in the encode(LogEvent,
> ByteBufferDestination) method. This reuses a ThreadLocal StringBuilder.
>
> Be aware of edge cases like occasional very large messages that result in
> the reusable StringBuilder taking up a lot of memory and never releasing
> it. (We trim if some configurable max size is exceeded.)
> You get some of this for free by extending AbstractStringLayout.
>
> I took a brief look at the BENCHMARK.txt file but didn’t have time to look
> in detail. A graph comparison would be very cool!
>
> Good luck, keep us posted!
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com> wrote:
> >
> > Hello,
> >
> > I am working on the next release of log4j2-logstash-layout
> > <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>,
> which
> > is an alternative to the default JsonLayout and allows custom JSON
> schemas.
> > There I achieved to get up to 5x speed up compared to JsonLayout[1] and I
> > want to stretch this further by reducing the GC load. Though it is really
> > difficult given Layout interface (practically) requires an output of type
> > String. I examined the internals of other gc-free layouts, e.g., Pattern,
> > Gelf, etc. Though each ends up making a call to StringBuilder#toString(),
> > which is not gc-free, to the best of my knowledge. Would anyone mind
> > shedding some light onto the issue, please?
> >
> > Best.
> >
> > [1] Please feel free to check JMH benchmarks
> > <
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java
> >
> > and their results
> > <
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt
> >.
> > Maybe there I am misconfiguring JsonLayout to cause it under-perform.
>
Re: GC Free Layouts
Posted by Volkan Yazıcı <vo...@gmail.com>.
I have pushed the garbage-free version of log4j2-logstash-layout to the
branch: https://github.com/vy/log4j2-logstash-layout/tree/json-generator
There you can also see the JMH results in a table.
On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <re...@gmail.com> wrote:
> Looks very nice!
>
> The non garbage-free implementation is in the toSerializable(LogEvent)
> method. As you point out, this often ends in a call to
> StringBuilder.toString().
>
> The garbage-free implementation is in the encode(LogEvent,
> ByteBufferDestination) method. This reuses a ThreadLocal StringBuilder.
>
> Be aware of edge cases like occasional very large messages that result in
> the reusable StringBuilder taking up a lot of memory and never releasing
> it. (We trim if some configurable max size is exceeded.)
> You get some of this for free by extending AbstractStringLayout.
>
> I took a brief look at the BENCHMARK.txt file but didn’t have time to look
> in detail. A graph comparison would be very cool!
>
> Good luck, keep us posted!
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com> wrote:
> >
> > Hello,
> >
> > I am working on the next release of log4j2-logstash-layout
> > <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>,
> which
> > is an alternative to the default JsonLayout and allows custom JSON
> schemas.
> > There I achieved to get up to 5x speed up compared to JsonLayout[1] and I
> > want to stretch this further by reducing the GC load. Though it is really
> > difficult given Layout interface (practically) requires an output of type
> > String. I examined the internals of other gc-free layouts, e.g., Pattern,
> > Gelf, etc. Though each ends up making a call to StringBuilder#toString(),
> > which is not gc-free, to the best of my knowledge. Would anyone mind
> > shedding some light onto the issue, please?
> >
> > Best.
> >
> > [1] Please feel free to check JMH benchmarks
> > <
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java
> >
> > and their results
> > <
> https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt
> >.
> > Maybe there I am misconfiguring JsonLayout to cause it under-perform.
>
Re: GC Free Layouts
Posted by Remko Popma <re...@gmail.com>.
Looks very nice!
The non garbage-free implementation is in the toSerializable(LogEvent) method. As you point out, this often ends in a call to StringBuilder.toString().
The garbage-free implementation is in the encode(LogEvent, ByteBufferDestination) method. This reuses a ThreadLocal StringBuilder.
Be aware of edge cases like occasional very large messages that result in the reusable StringBuilder taking up a lot of memory and never releasing it. (We trim if some configurable max size is exceeded.)
You get some of this for free by extending AbstractStringLayout.
I took a brief look at the BENCHMARK.txt file but didn’t have time to look in detail. A graph comparison would be very cool!
Good luck, keep us posted!
(Shameless plug) Every java main() method deserves http://picocli.info
> On Oct 23, 2018, at 6:40, Volkan Yazıcı <vo...@gmail.com> wrote:
>
> Hello,
>
> I am working on the next release of log4j2-logstash-layout
> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>, which
> is an alternative to the default JsonLayout and allows custom JSON schemas.
> There I achieved to get up to 5x speed up compared to JsonLayout[1] and I
> want to stretch this further by reducing the GC load. Though it is really
> difficult given Layout interface (practically) requires an output of type
> String. I examined the internals of other gc-free layouts, e.g., Pattern,
> Gelf, etc. Though each ends up making a call to StringBuilder#toString(),
> which is not gc-free, to the best of my knowledge. Would anyone mind
> shedding some light onto the issue, please?
>
> Best.
>
> [1] Please feel free to check JMH benchmarks
> <https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java>
> and their results
> <https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt>.
> Maybe there I am misconfiguring JsonLayout to cause it under-perform.