Skip to content

ZOOKEEPER-3823: Add a benchmark tool for testing watch feature performance - #1406

Open
maoling wants to merge 1 commit into
apache:masterfrom
maoling:ZOOKEEPER-3823
Open

maoling wants to merge 1 commit into
apache:masterfrom
maoling:ZOOKEEPER-3823

Conversation

@maoling

@maoling maoling commented Jul 20, 2020

Copy link
Copy Markdown
Member
  • Here is a detailed design document. Copying its abstract here.

This watch benchmark report is mainly organized as followed: Section 1 and 2: we introduce the resource, environment and software settings of our benchmark server. Section 3: we talk about the implementations of our watch benchmark tool. Section 4: we evaluate the experimental effects using our watch benchmark tool on the standard cloud machine from four dimensions: server mode, znode count, client threads, watch mode. Section 6: we look forward to our future work

@nkalmar nkalmar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @maoling , nice work, I left a few comments. I will also run the tool to test.

- Usages:


nohup ./zkWatchBenchmark.sh -root_path /bench-watch -threads 100 -znode_count 1000 -force -connect_string \n

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For readability, I would name this "isVerbose" or something similar.

private static void shutDownThreadPool(ExecutorService executorService) {
long shutDownStart = System.currentTimeMillis();
executorService.shutdown();
while (true) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

executorService.awaitTermination(); isntead?

ztzg pushed a commit that referenced this pull request Jan 7, 2021
### 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
RokLenarcic pushed a commit to RokLenarcic/zookeeper that referenced this pull request Aug 31, 2022
### 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
RokLenarcic pushed a commit to RokLenarcic/zookeeper that referenced this pull request Aug 31, 2022
### 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
RokLenarcic pushed a commit to RokLenarcic/zookeeper that referenced this pull request Aug 31, 2022
### 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
TRADITION("traditional_watch", "t"),
PERSISTENT("persistent_watch", "p");
private String name;
private String abbreviation;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ImmutableEnumChecker: enums should be immutable: 'WatchMode' has non-final field 'abbreviation'


Suggested change
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;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ImmutableEnumChecker: enums should be immutable: 'WatchMode' has non-final field 'name'


Suggested change
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();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IntLongMath: Expression of type int may overflow before being assigned to a long


Suggested change
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<>();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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<>();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


Suggested change
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("/");

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

StringSplitter: String.split(String) has surprising behavior


Suggested change
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 ]

Comment thread bin/zkWatchBenchmark.sh
if [ -e "$ZOOBIN/../libexec/zkEnv.sh" ]; then
. "$ZOOBINDIR"/../libexec/zkEnv.sh
else
. "$ZOOBINDIR"/zkEnv.sh

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ]

Comment thread bin/zkWatchBenchmark.sh
ZOOBINDIR="$(cd "${ZOOBIN}"; pwd)"

if [ -e "$ZOOBIN/../libexec/zkEnv.sh" ]; then
. "$ZOOBINDIR"/../libexec/zkEnv.sh

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ]

Comment thread bin/zkWatchBenchmark.sh Outdated
. "$ZOOBINDIR"/zkEnv.sh
fi

"$JAVA" -cp "$CLASSPATH" $JVMFLAGS \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ]

Comment thread bin/zkWatchBenchmark.sh Outdated
# use POSIX interface, symlink is followed automatically
ZOOBIN="${BASH_SOURCE-$0}"
ZOOBIN="$(dirname "${ZOOBIN}")"
ZOOBINDIR="$(cd "${ZOOBIN}"; pwd)"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💬 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")) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💬 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 ]

RokLenarcic pushed a commit to RokLenarcic/zookeeper that referenced this pull request Sep 3, 2022
### 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
@maoling

maoling commented Oct 12, 2025

Copy link
Copy Markdown
Member Author

Updates at 2025-10-12

  1. process review comments and rebase with master
  2. use AvgMinMaxPercentileCounter for memory efficiency

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants