[
https://issues.apache.org/jira/browse/LOG4J2-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862435#comment-13862435
]
Scott Deboy commented on LOG4J2-467:
------------------------------------
Here are my results from my Mac - two cached/two uncached runs.
CACHED
Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,023,291 ops/sec.
latency(ns): avg=4137.8 99% < 16384.0 99.99% < 2936012.8 (53351 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,542,271 ops/sec.
latency(ns): avg=2588.6 99% < 4505.6 99.99% < 2097152.0 (368968 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,895,205 ops/sec.
latency(ns): avg=2431.8 99% < 4096.0 99.99% < 2097152.0 (741385 samples)
Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,370,012 ops/sec.
latency(ns): avg=4088.8 99% < 16384.0 99.99% < 3355443.2 (57130 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,602,343 ops/sec.
latency(ns): avg=2448.9 99% < 3686.4 99.99% < 2097152.0 (406678 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,934,711 ops/sec.
latency(ns): avg=2436.2 99% < 4096.0 99.99% < 2446677.3 (748575 samples)
UNCACHED:
Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 6,818,683 ops/sec.
latency(ns): avg=3747.8 99% < 16384.0 99.99% < 2936012.8 (64379 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 3,915,888 ops/sec.
latency(ns): avg=2616.1 99% < 4096.0 99.99% < 2306867.2 (368855 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 1,911,439 ops/sec.
latency(ns): avg=2464.6 99% < 4096.0 99.99% < 2097152.0 (737069 samples)
Ranking:
1. Log4j2: Loggers all async (single thread): throughput: 7,449,397 ops/sec.
latency(ns): avg=3675.4 99% < 16384.0 99.99% < 2516582.4 (61476 samples)
2. Log4j2: Loggers all async (2 threads): throughput: 4,031,314 ops/sec.
latency(ns): avg=2578.6 99% < 3481.6 99.99% < 2516582.4 (388410 samples)
3. Log4j2: Loggers all async (4 threads): throughput: 2,625,581 ops/sec.
latency(ns): avg=2454.1 99% < 4096.0 99.99% < 2970965.3 (764774 samples)
> Thread name caching in async logger incompatible with use of Thread.setName()
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-467
> URL: https://issues.apache.org/jira/browse/LOG4J2-467
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-beta9
> Environment: Debian Squeeze amd64
> OpenJDK 7u25
> Reporter: Anthony Baldocchi
> Assignee: Remko Popma
> Fix For: 2.0-rc1
>
> Attachments: PerfTestDriver.java, PerfTestDriver.java
>
>
> AsyncLogger caches a thread's name in a thread-local info variable. I make
> use of a thread pool where the submitted Runnables call Thread.setName() at
> the beginning of their task and the thread name is included in the log
> message. For an example of this behavior, see
> org.jboss.netty.util.ThreadRenamingRunnable in Netty 3.x. With the cached
> thread name, the log messages will contain whatever name the thread had when
> it logged for the first time and so long as the thread doesn't terminate
> (such as in a core pool thread), all log messages involving this thread will
> be erroneous. If Thread.getName has a significant performance impact for
> async logging, I would be satisfied if this behavior were configurable,
> perhaps on a per-logger basis, so that the penalty only needs to be taken by
> users who make use of Thread.setName()
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
