logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elias Ross <er...@m-qube.com>
Subject Re: Concurrency Appender Proposal
Date Sat, 22 Jan 2005 00:51:02 GMT
On Thu, 2005-01-20 at 10:12, Ceki Gülcü wrote:
> Elias,
> 
> Thank you for your proposal. Would it possible for you to backup your
> proposal with prototype code? I'd be very interested in a comparative
> study between an Appender using the current concurrency model and an
> Appender following your improved model. A performance test involving
> several threads would be quite appropriate.
> 
> (Appender is an interface so one can easily swap implementations.)
> 
> How does that sound?

Sounds fantastic.

I wrote some simple tests.  Here's some of the code using the old
interface and the new one.

      ConcurrentAppender ca = new ConcurrentAppender() {
        protected void append(LoggingEvent event) {
          try { Thread.sleep(1); } catch (InterruptedException e) {}
        }
        protected void internalClose() {}
      };

      AppenderSkeleton as = new AppenderSkeleton() {
        protected void append(LoggingEvent event) {
          try { Thread.sleep(1); } catch (InterruptedException e) {}
        }
        public void close() {}
      };
                                                                                         
                                                                     Using 5 threads with
100 log statements, here's what I got (a representative sample):

     [java] AppenderSkeleton
     [java] Appender class org.apache.log4j.concurrent.PerformanceTest$2
     [java] Took 1066ms for 100 logs *  threads 5
 
     [java] ConcurrentAppender
     [java] Appender class org.apache.log4j.concurrent.PerformanceTest$1
     [java] Took 288ms for 100 logs *  threads 5

It's about 3-4 times as efficient.

Is there some place to put a patch?

I also wrote new ConsoleAppender, WriterAppender versions.  They perform
about the same as the old ones on a single processor machine, which
isn't a surprising finding, but it's good to know they are just as fast.

One thing I noticed was that Layouts were not thread-safe.  Most of the
code time is spent in that class *.  I changed the PatternConverter
class signature from:

  protected abstract void convert(LoggingEvent event);

to:

  protected abstract void convert(StringBuffer sb, LoggingEvent event);

and rewrote Layout in such a way that it is thread safe.  Obviously,
there would be compatibility issues, which is why I am thinking of
creating a separate Layout class to be used in this way.

* According to my last run 87% of the CPU time was spent formatting.  So
if you have 2 CPUs, 87% of the other CPU's time is waiting!



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message