Repository navigation
Conversation
| - Usages: | ||
|
|
||
|
|
||
| nohup ./zkWatchBenchmark.sh -root_path /bench-watch -threads 100 -znode_count 1000 -force -connect_string \n |
There was a problem hiding this comment.
I think nohup is unnecessary to include in the example command (while useful here I agree, there are other options, and everyone can decide how to handle the long runtime - at least this is how I see it, not a blocker though)
|
|
||
| ### zkWatchBenchmark.sh | ||
| - A benchmark tool that benchmarks the watch throughput and latency, which supports multiple clients threads, multiple watch modes | ||
| - See **ZOOKEEPER-3823** for the design document |
There was a problem hiding this comment.
this jira does not contain a design document. I don't think we need to link jira here.
|
|
||
| /** | ||
| * A benchmark tool that benchmarks the watch throughput and latency. | ||
| * See ZOOKEEPER-3823 for the design document |
There was a problem hiding this comment.
again, I think adding the jira number is unnecessary, as it does not contain a design document, or any further information.
| // wait for deleting all nodes | ||
| long deleteAwaitStart = System.currentTimeMillis(); | ||
| deleteNodeCountDownLatch.await(); | ||
| if (isDebug) { |
There was a problem hiding this comment.
For readability, I would name this "isVerbose" or something similar.
| private static void shutDownThreadPool(ExecutorService executorService) { | ||
| long shutDownStart = System.currentTimeMillis(); | ||
| executorService.shutdown(); | ||
| while (true) { |
There was a problem hiding this comment.
executorService.awaitTermination(); isntead?
### 1. Brief Introduction At first, I want to implement this benchmark tool based on the JMH. However, its has the following drawbacks: - For this situation:I want to simulate 1000000 requests with 100 concurrency client threads,What the parameters/options of JMH(mode,fork,threads,measurementIterations,measurementBatchSize) should I set? - Based on JMH, it also needs or use great effort to write a satisfactory script/CLI. Then, I want to implement the tool from scratch. Have to admit that: it's difficult to implement a tool as powerful as YCSB did. Finally, the YCSB is our choice. Here are its introductions: - [Home Page](https://github.com/brianfrankcooper/YCSB/blob/master/README.md) - [YCSB Paper](https://www2.cs.duke.edu/courses/fall13/cps296.4/838-CloudPapers/ycsb.pdf) is one of the best materials(A Great Reading) YCSB has the following pros: - It supports requests number and concurrency threads number that user appoints - It supports various workloads for different read/write/insert/scan request ratio - It supports different request distributions(uniform, zipfian, latest) - It can output the benchmark results to different report formats(e.g.: `hdrhistogram`) - It has abundant metrics: throughout, avg/min/max/percentile latency, etc. - It has a detailed benchmark usage documentation ### 2. Benchmark Report Here is a [WIP Benchmark Report](https://docs.google.com/document/d/1_kGwnx5y7SYLSLtEPbkGJkrWbnsSftwNTvi8RCC9L7Y/edit?usp=sharing) which tested on the standard cloud machines with release-3.6.1(still a very messy draft and lots of works to do in the future). Two conspicuous performance issues: #### 2.1. Tail latency The tail latency is sometimes up to 200 ms. we can observer long-fat tail. Look at [figure-1](https://issues.apache.org/jira/secure/attachment/13017005/bm-read-histogram.png) and [figure-2](https://issues.apache.org/jira/secure/attachment/13017004/bm-update-histogram.png). We demand a smoother latency curve. The potential causes: - Java GC - The commit algorithm which schedules read/write requests in the `CommitProcessor`. (Most likely place where significantly improves the performance) #### 2.2. Connection numbers When connection numbers >= 1000, the throughput and latency extremely degrade. Look at [figure-3](https://issues.apache.org/jira/secure/attachment/13017006/bm-clients.png). Using the TCP connection can guarantee the message/packet order, but TCP connections that one Linux VM could support/hold is limited. Perhaps based/focused on Netty, we can improve this issue further. ### 3. Related Works 3.1 [YCSB-PR-1327](brianfrankcooper/YCSB#1327) 3.2 [ZooKeeper Watch Benchmark Tool](#1406) Author: maoling <maoling199210191@sina.com> Reviewers: Mate Szalay-Beko <symat@apache.org>, Damien Diederen <ddiederen@apache.org> Closes #1558 from maoling/ZOOKEEPER-3264
### 1. Brief Introduction At first, I want to implement this benchmark tool based on the JMH. However, its has the following drawbacks: - For this situation:I want to simulate 1000000 requests with 100 concurrency client threads,What the parameters/options of JMH(mode,fork,threads,measurementIterations,measurementBatchSize) should I set? - Based on JMH, it also needs or use great effort to write a satisfactory script/CLI. Then, I want to implement the tool from scratch. Have to admit that: it's difficult to implement a tool as powerful as YCSB did. Finally, the YCSB is our choice. Here are its introductions: - [Home Page](https://github.com/brianfrankcooper/YCSB/blob/master/README.md) - [YCSB Paper](https://www2.cs.duke.edu/courses/fall13/cps296.4/838-CloudPapers/ycsb.pdf) is one of the best materials(A Great Reading) YCSB has the following pros: - It supports requests number and concurrency threads number that user appoints - It supports various workloads for different read/write/insert/scan request ratio - It supports different request distributions(uniform, zipfian, latest) - It can output the benchmark results to different report formats(e.g.: `hdrhistogram`) - It has abundant metrics: throughout, avg/min/max/percentile latency, etc. - It has a detailed benchmark usage documentation ### 2. Benchmark Report Here is a [WIP Benchmark Report](https://docs.google.com/document/d/1_kGwnx5y7SYLSLtEPbkGJkrWbnsSftwNTvi8RCC9L7Y/edit?usp=sharing) which tested on the standard cloud machines with release-3.6.1(still a very messy draft and lots of works to do in the future). Two conspicuous performance issues: #### 2.1. Tail latency The tail latency is sometimes up to 200 ms. we can observer long-fat tail. Look at [figure-1](https://issues.apache.org/jira/secure/attachment/13017005/bm-read-histogram.png) and [figure-2](https://issues.apache.org/jira/secure/attachment/13017004/bm-update-histogram.png). We demand a smoother latency curve. The potential causes: - Java GC - The commit algorithm which schedules read/write requests in the `CommitProcessor`. (Most likely place where significantly improves the performance) #### 2.2. Connection numbers When connection numbers >= 1000, the throughput and latency extremely degrade. Look at [figure-3](https://issues.apache.org/jira/secure/attachment/13017006/bm-clients.png). Using the TCP connection can guarantee the message/packet order, but TCP connections that one Linux VM could support/hold is limited. Perhaps based/focused on Netty, we can improve this issue further. ### 3. Related Works 3.1 [YCSB-PR-1327](brianfrankcooper/YCSB#1327) 3.2 [ZooKeeper Watch Benchmark Tool](apache#1406) Author: maoling <maoling199210191@sina.com> Reviewers: Mate Szalay-Beko <symat@apache.org>, Damien Diederen <ddiederen@apache.org> Closes apache#1558 from maoling/ZOOKEEPER-3264
### 1. Brief Introduction At first, I want to implement this benchmark tool based on the JMH. However, its has the following drawbacks: - For this situation:I want to simulate 1000000 requests with 100 concurrency client threads,What the parameters/options of JMH(mode,fork,threads,measurementIterations,measurementBatchSize) should I set? - Based on JMH, it also needs or use great effort to write a satisfactory script/CLI. Then, I want to implement the tool from scratch. Have to admit that: it's difficult to implement a tool as powerful as YCSB did. Finally, the YCSB is our choice. Here are its introductions: - [Home Page](https://github.com/brianfrankcooper/YCSB/blob/master/README.md) - [YCSB Paper](https://www2.cs.duke.edu/courses/fall13/cps296.4/838-CloudPapers/ycsb.pdf) is one of the best materials(A Great Reading) YCSB has the following pros: - It supports requests number and concurrency threads number that user appoints - It supports various workloads for different read/write/insert/scan request ratio - It supports different request distributions(uniform, zipfian, latest) - It can output the benchmark results to different report formats(e.g.: `hdrhistogram`) - It has abundant metrics: throughout, avg/min/max/percentile latency, etc. - It has a detailed benchmark usage documentation ### 2. Benchmark Report Here is a [WIP Benchmark Report](https://docs.google.com/document/d/1_kGwnx5y7SYLSLtEPbkGJkrWbnsSftwNTvi8RCC9L7Y/edit?usp=sharing) which tested on the standard cloud machines with release-3.6.1(still a very messy draft and lots of works to do in the future). Two conspicuous performance issues: #### 2.1. Tail latency The tail latency is sometimes up to 200 ms. we can observer long-fat tail. Look at [figure-1](https://issues.apache.org/jira/secure/attachment/13017005/bm-read-histogram.png) and [figure-2](https://issues.apache.org/jira/secure/attachment/13017004/bm-update-histogram.png). We demand a smoother latency curve. The potential causes: - Java GC - The commit algorithm which schedules read/write requests in the `CommitProcessor`. (Most likely place where significantly improves the performance) #### 2.2. Connection numbers When connection numbers >= 1000, the throughput and latency extremely degrade. Look at [figure-3](https://issues.apache.org/jira/secure/attachment/13017006/bm-clients.png). Using the TCP connection can guarantee the message/packet order, but TCP connections that one Linux VM could support/hold is limited. Perhaps based/focused on Netty, we can improve this issue further. ### 3. Related Works 3.1 [YCSB-PR-1327](brianfrankcooper/YCSB#1327) 3.2 [ZooKeeper Watch Benchmark Tool](apache#1406) Author: maoling <maoling199210191@sina.com> Reviewers: Mate Szalay-Beko <symat@apache.org>, Damien Diederen <ddiederen@apache.org> Closes apache#1558 from maoling/ZOOKEEPER-3264
### 1. Brief Introduction At first, I want to implement this benchmark tool based on the JMH. However, its has the following drawbacks: - For this situation:I want to simulate 1000000 requests with 100 concurrency client threads,What the parameters/options of JMH(mode,fork,threads,measurementIterations,measurementBatchSize) should I set? - Based on JMH, it also needs or use great effort to write a satisfactory script/CLI. Then, I want to implement the tool from scratch. Have to admit that: it's difficult to implement a tool as powerful as YCSB did. Finally, the YCSB is our choice. Here are its introductions: - [Home Page](https://github.com/brianfrankcooper/YCSB/blob/master/README.md) - [YCSB Paper](https://www2.cs.duke.edu/courses/fall13/cps296.4/838-CloudPapers/ycsb.pdf) is one of the best materials(A Great Reading) YCSB has the following pros: - It supports requests number and concurrency threads number that user appoints - It supports various workloads for different read/write/insert/scan request ratio - It supports different request distributions(uniform, zipfian, latest) - It can output the benchmark results to different report formats(e.g.: `hdrhistogram`) - It has abundant metrics: throughout, avg/min/max/percentile latency, etc. - It has a detailed benchmark usage documentation ### 2. Benchmark Report Here is a [WIP Benchmark Report](https://docs.google.com/document/d/1_kGwnx5y7SYLSLtEPbkGJkrWbnsSftwNTvi8RCC9L7Y/edit?usp=sharing) which tested on the standard cloud machines with release-3.6.1(still a very messy draft and lots of works to do in the future). Two conspicuous performance issues: #### 2.1. Tail latency The tail latency is sometimes up to 200 ms. we can observer long-fat tail. Look at [figure-1](https://issues.apache.org/jira/secure/attachment/13017005/bm-read-histogram.png) and [figure-2](https://issues.apache.org/jira/secure/attachment/13017004/bm-update-histogram.png). We demand a smoother latency curve. The potential causes: - Java GC - The commit algorithm which schedules read/write requests in the `CommitProcessor`. (Most likely place where significantly improves the performance) #### 2.2. Connection numbers When connection numbers >= 1000, the throughput and latency extremely degrade. Look at [figure-3](https://issues.apache.org/jira/secure/attachment/13017006/bm-clients.png). Using the TCP connection can guarantee the message/packet order, but TCP connections that one Linux VM could support/hold is limited. Perhaps based/focused on Netty, we can improve this issue further. ### 3. Related Works 3.1 [YCSB-PR-1327](brianfrankcooper/YCSB#1327) 3.2 [ZooKeeper Watch Benchmark Tool](apache#1406) Author: maoling <maoling199210191@sina.com> Reviewers: Mate Szalay-Beko <symat@apache.org>, Damien Diederen <ddiederen@apache.org> Closes apache#1558 from maoling/ZOOKEEPER-3264
a785d18 to
3710c60
Compare
| TRADITION("traditional_watch", "t"), | ||
| PERSISTENT("persistent_watch", "p"); | ||
| private String name; | ||
| private String abbreviation; |
There was a problem hiding this comment.
ImmutableEnumChecker: enums should be immutable: 'WatchMode' has non-final field 'abbreviation'
| private String abbreviation; | |
| private final String abbreviation; |
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| // the traditional one-off watch | ||
| TRADITION("traditional_watch", "t"), | ||
| PERSISTENT("persistent_watch", "p"); | ||
| private String name; |
There was a problem hiding this comment.
ImmutableEnumChecker: enums should be immutable: 'WatchMode' has non-final field 'name'
| private String name; | |
| private final String name; |
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
|
|
||
| // receive, loss notifications count and ratio summary | ||
| double receivedRatio = (double) copyLatencyList.size() / (double) (watchMultiple * clientThreads * znodeCount); | ||
| long lossCount = watchMultiple * clientThreads * znodeCount - copyLatencyList.size(); |
There was a problem hiding this comment.
IntLongMath: Expression of type int may overflow before being assigned to a long
| long lossCount = watchMultiple * clientThreads * znodeCount - copyLatencyList.size(); | |
| long lossCount = (long) watchMultiple * clientThreads * znodeCount - copyLatencyList.size(); |
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| private static final Logger LOG = LoggerFactory.getLogger(WatchBenchmarkTool.class); | ||
|
|
||
| private static final ConcurrentHashMap<Integer, Long> watchTriggerTimeMap = new ConcurrentHashMap<>(); | ||
| private static final List<Long> latencyList = new Vector<>(); |
There was a problem hiding this comment.
JdkObsolete: Vector performs synchronization that is usually unnecessary; prefer ArrayList.
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| * A deep copy of the latencyList, to avoid this situation when we statistics latencyList | ||
| * at the same time, watch events in flight are added to latencyList concurrently. | ||
| */ | ||
| List<Long> copyLatencyList = new LinkedList<>(); |
There was a problem hiding this comment.
JdkObsolete: It is very rare for LinkedList to out-perform ArrayList or ArrayDeque. Avoid it unless you're willing to invest a lot of time into benchmarking. Caveat: LinkedList supports null elements, but ArrayDeque does not.
| List<Long> copyLatencyList = new LinkedList<>(); | |
| List<Long> copyLatencyList = new ArrayList<>(); |
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| } | ||
| } else { | ||
| // help user to create the znode: rootPath | ||
| String[] paths = rootPath.split("/"); |
There was a problem hiding this comment.
StringSplitter: String.split(String) has surprising behavior
| String[] paths = rootPath.split("/"); | |
| List<String> paths = Splitter.on('/').splitToList(rootPath); |
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| if [ -e "$ZOOBIN/../libexec/zkEnv.sh" ]; then | ||
| . "$ZOOBINDIR"/../libexec/zkEnv.sh | ||
| else | ||
| . "$ZOOBINDIR"/zkEnv.sh |
There was a problem hiding this comment.
SC1091: Not following: ./zkEnv.sh was not specified as input (see shellcheck -x).
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| ZOOBINDIR="$(cd "${ZOOBIN}"; pwd)" | ||
|
|
||
| if [ -e "$ZOOBIN/../libexec/zkEnv.sh" ]; then | ||
| . "$ZOOBINDIR"/../libexec/zkEnv.sh |
There was a problem hiding this comment.
SC1091: Not following: ./../libexec/zkEnv.sh was not specified as input (see shellcheck -x).
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| . "$ZOOBINDIR"/zkEnv.sh | ||
| fi | ||
|
|
||
| "$JAVA" -cp "$CLASSPATH" $JVMFLAGS \ |
There was a problem hiding this comment.
SC2086: Double quote to prevent globbing and word splitting.
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| # use POSIX interface, symlink is followed automatically | ||
| ZOOBIN="${BASH_SOURCE-$0}" | ||
| ZOOBIN="$(dirname "${ZOOBIN}")" | ||
| ZOOBINDIR="$(cd "${ZOOBIN}"; pwd)" |
There was a problem hiding this comment.
SC2164: Use 'cd ... || exit' or 'cd ... || return' in case cd fails.
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| zk.addWatch(rootPath + "/" + i, simpleWatcher, PERSISTENT); | ||
| } | ||
| } catch (KeeperException | InterruptedException e) { | ||
| e.printStackTrace(); |
There was a problem hiding this comment.
💬 7 similar findings have been found in this PR
CatchAndPrintStackTrace: Logging or rethrowing exceptions should usually be preferred to catching and calling printStackTrace
🔎 Expand here to view all instances of this finding
| File Path | Line Number |
|---|---|
| zookeeper-server/src/main/java/org/apache/zookeeper/server/watch/WatchBenchmarkTool.java | 497 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/watch/WatchBenchmarkTool.java | 524 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/watch/WatchBenchmarkTool.java | 201 |
| zookeeper-jute/target/generated-sources/java/org/apache/zookeeper/server/quorum/QuorumPacket.java | 126 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/watch/WatchBenchmarkTool.java | 480 |
| zookeeper-jute/target/generated-sources/java/org/apache/zookeeper/proto/GetMaxChildrenRequest.java | 61 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/watch/WatchBenchmarkTool.java | 544 |
Visit the Lift Web Console to find more details in your report.
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
| try { | ||
| ZooKeeper zk = initZKClient(); | ||
| if (zk.exists(rootPath, null) != null) { | ||
| if (!cmd.hasOption("force")) { |
There was a problem hiding this comment.
💬 6 similar findings have been found in this PR
RESOURCE_LEAK: resource of type org.apache.zookeeper.ZooKeeper acquired by call to initZKClient() at line 267 is not released after line 269.
🔎 Expand here to view all instances of this finding
| File Path | Line Number |
|---|---|
| zookeeper-server/src/main/java/org/apache/zookeeper/server/persistence/SnapStream.java | 132 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/persistence/SnapStream.java | 132 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java | 1366 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java | 1335 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/watch/WatchBenchmarkTool.java | 276 |
| zookeeper-server/src/main/java/org/apache/zookeeper/server/persistence/SnapStream.java | 107 |
Visit the Lift Web Console to find more details in your report.
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
| Command | Usage |
|---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
### 1. Brief Introduction At first, I want to implement this benchmark tool based on the JMH. However, its has the following drawbacks: - For this situation:I want to simulate 1000000 requests with 100 concurrency client threads,What the parameters/options of JMH(mode,fork,threads,measurementIterations,measurementBatchSize) should I set? - Based on JMH, it also needs or use great effort to write a satisfactory script/CLI. Then, I want to implement the tool from scratch. Have to admit that: it's difficult to implement a tool as powerful as YCSB did. Finally, the YCSB is our choice. Here are its introductions: - [Home Page](https://github.com/brianfrankcooper/YCSB/blob/master/README.md) - [YCSB Paper](https://www2.cs.duke.edu/courses/fall13/cps296.4/838-CloudPapers/ycsb.pdf) is one of the best materials(A Great Reading) YCSB has the following pros: - It supports requests number and concurrency threads number that user appoints - It supports various workloads for different read/write/insert/scan request ratio - It supports different request distributions(uniform, zipfian, latest) - It can output the benchmark results to different report formats(e.g.: `hdrhistogram`) - It has abundant metrics: throughout, avg/min/max/percentile latency, etc. - It has a detailed benchmark usage documentation ### 2. Benchmark Report Here is a [WIP Benchmark Report](https://docs.google.com/document/d/1_kGwnx5y7SYLSLtEPbkGJkrWbnsSftwNTvi8RCC9L7Y/edit?usp=sharing) which tested on the standard cloud machines with release-3.6.1(still a very messy draft and lots of works to do in the future). Two conspicuous performance issues: #### 2.1. Tail latency The tail latency is sometimes up to 200 ms. we can observer long-fat tail. Look at [figure-1](https://issues.apache.org/jira/secure/attachment/13017005/bm-read-histogram.png) and [figure-2](https://issues.apache.org/jira/secure/attachment/13017004/bm-update-histogram.png). We demand a smoother latency curve. The potential causes: - Java GC - The commit algorithm which schedules read/write requests in the `CommitProcessor`. (Most likely place where significantly improves the performance) #### 2.2. Connection numbers When connection numbers >= 1000, the throughput and latency extremely degrade. Look at [figure-3](https://issues.apache.org/jira/secure/attachment/13017006/bm-clients.png). Using the TCP connection can guarantee the message/packet order, but TCP connections that one Linux VM could support/hold is limited. Perhaps based/focused on Netty, we can improve this issue further. ### 3. Related Works 3.1 [YCSB-PR-1327](brianfrankcooper/YCSB#1327) 3.2 [ZooKeeper Watch Benchmark Tool](apache#1406) Author: maoling <maoling199210191@sina.com> Reviewers: Mate Szalay-Beko <symat@apache.org>, Damien Diederen <ddiederen@apache.org> Closes apache#1558 from maoling/ZOOKEEPER-3264
3710c60 to
720eb26
Compare
|
Updates at 2025-10-12
|
720eb26 to
9b41e6d
Compare
9b41e6d to
5455d86
Compare
WindowsOS is included in JIRA