I think we need some comparisons on the log4j side: file appender with 256k buffer size, random access file appender with 256k buffer size (which appears to be the default), and memory mapped file appender. It'd be cool to see how these compose with async logging enabled in both log4j and logback.
On 5 February 2017 at 16:06, Apache <ralph.go...@dslextreme.com> wrote: > You should run the code at https://github.com/ceki/logback-perf to > compare your results to Ceki’s. You also should capture the cpubenchmark > speed of your processor and get the speed of your hard drive. I used > Blackmagic speed test on my Mac. I am capturing my results in a Google > spreadsheet. I will post the like once I have it. > > Ralph > > On Feb 5, 2017, at 1:48 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > If you want, I can run tests on Windows once the build works on Windows > again. > > Let me know what args/command line... > > Gary > > On Feb 5, 2017 11:58 AM, "Apache" <ralph.go...@dslextreme.com> wrote: > >> I guess my MacBook Pro must fit in the Slow CPU/Fast Hard drive category. >> With Logback 1.10 and -t 4 now get >> >> Benchmark Mode Samples >> Score Error Units >> o.a.l.l.p.j.FileAppenderBenchmark.julFile thrpt 20 >> 98187.673 ± 4935.712 ops/s >> o.a.l.l.p.j.FileAppenderBenchmark.log4j1File thrpt 20 >> 842374.496 ± 6762.712 ops/s >> o.a.l.l.p.j.FileAppenderBenchmark.log4j2File thrpt 20 >> 1853062.583 ± 67032.225 ops/s >> o.a.l.l.p.j.FileAppenderBenchmark.log4j2RAF thrpt 20 >> 2036011.226 ± 53208.281 ops/s >> o.a.l.l.p.j.FileAppenderBenchmark.logbackFile thrpt 20 >> 999667.438 ± 12074.003 ops/s >> >> I’ll have to try this on one my VMs at work. We don’t run anything >> directly on bare metal any more. >> >> Ralph >> >> On Feb 5, 2017, at 9:40 AM, Apache <ralph.go...@dslextreme.com> wrote: >> >> Ceki finally fixed some of the performance problems in the FileAppender. >> See https://logback.qos.ch/news.html and https://docs.google >> .com/spreadsheets/d/1cpb5D7qnyye4W0RTlHUnXedYK98catNZytYIu5D >> 91m0/edit#gid=0. I suspect we have a few optimizations we can make. >> >> Ralph >> >> >> > -- Matt Sicker <boa...@gmail.com>
