Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
Also recent addition of "write touch" seems to improve throughput
considerably, so the numbers posted above are irrelevant now.
---
If your project is set up for it, you can rep
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
Things still TODO / TBD in this PR:
- **Why on extreme loads the new version has significantly worse tail
latency?**
- StringBuilderEncoder.DEFAULT_BYTE_BUFFER_SIZE (8k) effectively
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
New latency benchmarking results "done right" (with Pacer), On 4-core MBP
with SSD, benchmarking with 3 threads:
- [200
messages/sec/thread](https://cdn.rawgit.co
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
@remkop I have not competed this PR yet, there are a few more things need
to be done. I will try to complete PR in the next weekend. Also I've just sent
ICLA to secret...@apache.org
-
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
@mikaelstaldal it is configured for at most 1 second latency. Maybe on your
machine some pause takes more.
BTW jvm crash is not a mystery anymore, it was because of reads after
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
Throughput comparison
First number is the number of threads, "150" is the message size.
Before this PR
```
1 - o.a.l.l.p.j.Log4j2AppenderComparisonBenchmark.e
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
Latency comparison
```
java -jar log4j-perf/target/benchmarks.jar
".*Log4j2AppenderLatencyBenchmark.end2end" -f 1 -wi 1 -i 30 -t 2 -p
loggerType=MMap
```
On m
Github user leventov commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/87#discussion_r125168798
--- Diff:
log4j-core/src/main/java/org/apache/logging/log4j/core/appender/ThreadHints.java
---
@@ -0,0 +1,63 @@
+/*
+ * Licensed to the
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
@remkop note that this PR is primarily about _latency_, not throughput at
all. I will do some testing, but if the throughput will degrade (that I expect
in a single-thread case), and latency
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/87
@remkop
> MemoryMappedFileManager::switchRegion and
::closeAndSwitchRegionWhileLocked should not throw Error: generally a logging
problem should not bring down the application.
GitHub user leventov opened a pull request:
https://github.com/apache/logging-log4j2/pull/87
[LOG4J2-928] Mostly wait-free MemoryMappedFileManager
A pull request for https://issues.apache.org/jira/browse/LOG4J2-928.
This PR is not complete - it lacks tests and benchmarks
Github user leventov closed the pull request at:
https://github.com/apache/logging-log4j2/pull/71
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
[
https://issues.apache.org/jira/browse/LOG4J2-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049773#comment-16049773
]
Roman Leventov commented on LOG4J2-1874:
Thanks for review!
1) Yes, it
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop thanks for commitment
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop any extra comments on this?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop I did that for log4j-core only. Yes, it passes.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop this test used to depend on specific line numbers in this test.
Made it more generic.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user leventov commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/71#discussion_r115515373
--- Diff:
log4j-core/src/main/java/org/apache/logging/log4j/core/layout/StringBuilderEncoder.java
---
@@ -32,9 +32,14 @@
public class
Github user leventov commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/71#discussion_r115512718
--- Diff:
log4j-core/src/main/java/org/apache/logging/log4j/core/layout/StringBuilderEncoder.java
---
@@ -32,9 +32,14 @@
public class
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop thanks for review. Replaced custom class in ThreadLocal with
`Object[]`. Fixed a bug in `TextEncoderHelper`,
`ThrowableProxyTest.testCircularSuppressedExceptions()` passes now
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
@remkop renamed. Yes, OutputStreamManager.write(byte[], int, int) has the
same semantics.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user leventov commented on the issue:
https://github.com/apache/logging-log4j2/pull/71
> A complicating factor is that there may be users who subclassed any of
these classes, and we don't want to break their stuff.
If users could implement `ByteBufferDes
22 matches
Mail list logo
