Hello Joern,
Thank you for this post. Looking at PerformanceTest, and in particular
the createCallStack() method, it appears that stack traces used in the
generated logging events will have exactly 5 elements. If caller data
collection is enabled, in a production system, the computed caller
data could easily have 20 or more elements.
Given its sheer size, caller data may overwhelm all other elements in
a LoggingEvent. Even in case where caller data has only 5 elements, it
probably accounts for two thirds, or at least half, the size of a
serialized logging event.
By any yardstick, caller data is a very significant factor when
benchmarking logging event serialization.
Joern Huxhorn wrote:
Hey guys,
I've implemented protobuf Serializer/Deserializer for Lilith and have
done some more benchmarks:
http://apps.sourceforge.net/trac/lilith/wiki/SerializationPerformance
protobuf is really, really fast and creates the smallest data of all
tested mechanisms!! Uncompressed protobuf is only slightly larger than
compressed java serialization!
I'll definitely use it for both my appender and the file format in the
next Lilith version...
The benchmark code can be found here:
http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith/src/test/java/de/huxhorn/lilith/PerformanceTest.java
It's using the same LoggingEvents all the time so it has a corpus as
suggested below, right? The only problematic bit is that it's using
Lilith events and not Logback events but they should be comparable, I
think.
Feel free to bash me if you know a better way to benchmark this :)
The proto file can be found here:
http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data/logging-protobuf/src/main/protobuf/LoggingProto.proto
and all protobuf related code is here:
http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data/logging-protobuf/src/main/java/de/huxhorn/lilith/data/logging/protobuf/
I've also added streamingSerializationWrite and
streamingSerializationRead which mimics the way Logbacks SocketAppender
is currently serializing. This method has the downside that it's not
possible to send separate events to multiple recipients - which I do
with my multiplexers - without serializing multiple times.
Joern.
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
