Yes, that is still the standard approach most people use and is the only way to provide a head-to-head comparison against the logging frameworks.
Ralph > On Feb 6, 2017, at 8:02 AM, Matt Sicker <boa...@gmail.com> wrote: > > This is all in a synchronous appender, right? Either way, that's rather > interesting. > > On 6 February 2017 at 07:54, Apache <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > Someone posted numbers on the Logback user’s list that match mine. It shows > Logback 1.1.9 was pretty terrible, 1.1.10 is somewhat better and 1.2-SNAPSHOT > is on par or slightly better than Log4j 2. > > Ralph > >> On Feb 5, 2017, at 3:25 PM, Matt Sicker <boa...@gmail.com >> <mailto:boa...@gmail.com>> wrote: >> >> 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 >> <mailto:ralph.go...@dslextreme.com>> wrote: >> You should run the code at https://github.com/ceki/logback-perf >> <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 >>> <mailto: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 >>> <mailto: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 >>>> <mailto:ralph.go...@dslextreme.com>> wrote: >>>> >>>> Ceki finally fixed some of the performance problems in the FileAppender. >>>> See https://logback.qos.ch/news.html <https://logback.qos.ch/news.html> >>>> and >>>> https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0 >>>> >>>> <https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0RTlHUnXedYK98catNZytYIu5D91m0/edit#gid=0>. >>>> I suspect we have a few optimizations we can make. >>>> >>>> Ralph >>> >> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> > > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>