Skip to content

Commit

Permalink
udpate iframe display
Browse files Browse the repository at this point in the history 
Signed-off-by: YiniXu9506 <[email protected]>
  • Loading branch information
@TomShawn
TomShawn authored and YiniXu9506 committed Jul 28, 2021
1 parent 5d74f1b commit b24e7f3
Show file tree
Hide file tree
Showing 4 changed files with 150 additions and 115 deletions.
19 changes: 19 additions & 0 deletions assets/sass/style.sass
View file
Original file line number Diff line number Diff line change
Expand Up @@ -396,3 +396,22 @@ a

.highlight
overflow-x: scroll

.iframe-figure
width: 100% !important

.iframe-container
overflow: hidden
/* 16:9 aspect ratio */
padding-top: 56.25%
position: relative

.iframe-container iframe
border: 0
height: 100%
left: 0
position: absolute
top: 0
width: 100%


212 changes: 108 additions & 104 deletions content/docs/5.1/deploy/performance/instructions.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,148 +7,149 @@ menu:
weight: 6
---

TiKV delivers predictable throughput and latency at all scales on commodity hardware. This page provides an step-by-step tutorial about industry-standard benchmarks [YCSB](https://github.com/brianfrankcooper/YCSB) on TiKV.
TiKV delivers predictable throughput and latency at all scales on commodity hardware. This document provides a step-by-step tutorial on performing a benchmark test using the industry-standard benchmark tool [YCSB](https://github.com/brianfrankcooper/YCSB) on TiKV.

## Step 1. Setup the environment.
## Step 1. Set up the environment

1. Prepare 1 node for the YCSB benchmark worker, 1 node for PD, 3 nodes for TiKV.
1. Prepare 1 node for the YCSB benchmark worker, 1 node for Placement Driver (PD), and 3 nodes for TiKV.

Here is the recommended hardware configuration:
The following table shows the recommended hardware configuration:

| **Component** | **CPU** | **Memory** | **Storage** | **Network** | **Instance** |
| ------------- | ---------------- | -------------- | --------------- | ----------- | ------------------------------- |
| YSCB worker | 8 cores or above | 8 GB or above | no requirements | Gigabit LAN | 1 |
| PD | 4 cores or above | 8 GB or above | SAS, 200 GB+ | Gigabit LAN | 1 |
| Monitor | 4 cores or above | 8 GB or above | SAS, 200 GB+ | Gigabit LAN | 1 (can be the same as PD nodes) |
| TiKV | 8 cores or above | 32 GB or above | SSD, 200 GB+ | Gigabit LAN | 3 |
| **Component** | **CPU** | **Memory** | **Storage** | **Network** | **Instance** |
| ------------- | ---------------- | -------------- | -------------------- | ----------- | ------------------------------- |
| YSCB worker | 8 cores or above | 8 GB or above | No requirement | Gigabit LAN | 1 |
| PD | 4 cores or above | 8 GB or above | SAS, 200 GB+ | Gigabit LAN | 1 |
| Monitor | 4 cores or above | 8 GB or above | SAS, 200 GB or above | Gigabit LAN | 1 (can be the same as PD nodes) |
| TiKV | 8 cores or above | 32 GB or above | SSD, 200 GB or above | Gigabit LAN | 3 |

{{< info >}}
Use local SSD instance store volumes. Local SSDs are low latency disks attached to each node, which maximizes performance. We do not recommend using network-attached block storage. We highly recommend you depoly TiKV over NVMe SSDs in order to maximizes the ability of it.
{{< /info >}}
{{< info >}}
It is recommended to use local SSDs as the store volume for the instances. Local SSDs are low-latency disks attached to each node and can maximize performance. It is not recommended to use the network-attached block storage. It is recommended to deploy TiKV on NVMe SSDs to maximize its capacity.
{{< /info >}}

2. Prepare services for the control node and component nodes.

For the control node, we require:

| package | version | comment |
| :------ | :------------: | :------------------ |
| sshpass | 1.06 or above | remote control |
| TiUP | 0.6.2 or above | depoly TiKV cluster |

For the component node:

| package | version | comment |
| :------ | :-------------: | :------------------------: |
| sshpass | 1.06 or above | remote control |
| numa | 2.0.12 or above | memory allocation strategy |
| tar | no requirements | unzip |

For the YCSB node:

| package | version | comment |
| :-------------------------------------------- | :-------------: | :-------: |
| [go-ycsb](https://github.com/pingcap/go-ycsb) | no requirements | benchmark |
For the control node, the following requirements must be met:

| Package | Version | Note |
| :------ | :------------: | :--------------------- |
| sshpass | 1.06 or later | For remote control |
| TiUP | 0.6.2 or later | To deploy TiKV cluster |

For the component node, the following requirements must be met:

| Package | Version | Note |
| :------ | :-------------: | :----------------------------: |
| sshpass | 1.06 or later | For remote control |
| numa | 2.0.12 or later | The memory allocation strategy |
| tar | No requirement | For unzipping |

For the YCSB node:

| Package | Version | Note |
| :-------------------------------------------- | :------------: | :-----------: |
| [go-ycsb](https://github.com/pingcap/go-ycsb) | No requirement | For benchmark |

{{< info >}}
You can install [TiUP](https://github.com/pingcap/tiup) as described in [TiKV in 5 Minutes](../../tikv-in-5-minutes).
{{< /info >}}

## Step 2. Deploy a TiKV cluster

1. You can use the following topology to deploy your benchmark cluster via `tiup cluster`. For more information, see [Production Deployment](../../install/production). Save the content below as `topology.yaml`:

```yaml
global:
user: "tikv"
ssh_port: 22
deploy_dir: "/tikv-deploy"
data_dir: "/tikv-data"
server_configs: {}
pd_servers:
- host: 10.0.1.1
tikv_servers:
- host: 10.0.1.2
- host: 10.0.1.3
- host: 10.0.1.4
monitoring_servers:
- host: 10.0.1.5
grafana_servers:
- host: 10.0.1.6
```
2. Deploy the cluster:
{{< info >}}
You can install [TiUP](https://github.com/pingcap/tiup) as described in [TiKV in 5 Minutes](../../tikv-in-5-minutes).
{{< /info >}}
```sh
tiup cluster deploy [cluster-name] [cluster-version] topology.yaml
```

## Step 2. Deploy a cluster

1. We could use the following topology to deploy our benchmark cluster via `tiup cluster`. **For more information, see [Production Deployment](../../install/production)**. Save the content below as `topology.yaml`:
```yaml
global:
user: "tikv"
ssh_port: 22
deploy_dir: "/tikv-deploy"
data_dir: "/tikv-data"
server_configs: {}
pd_servers:
- host: 10.0.1.1
tikv_servers:
- host: 10.0.1.2
- host: 10.0.1.3
- host: 10.0.1.4
monitoring_servers:
- host: 10.0.1.5
grafana_servers:
- host: 10.0.1.6
```
3. Start the cluster:

2. Deploy the cluster:
```sh
tiup cluster deploy [cluster-name] [cluster-version] topology.yaml
```
```sh
tiup cluster start [cluster-name]
```

3. Start the cluster:
```sh
tiup cluster start [cluster-name]
```
4. You can check the cluster information:

4. You can inspect the cluster information:
```sh
tiup cluster display [cluster-name]
```
```sh
tiup cluster display [cluster-name]
```

## Step 3. Run a YCSB workload

YCSB has six kinds of workloads whose main difference are the portion of different operations:
This section introduces the types of core workloads and the recommended sequence for running the workloads. Most of the content in this section comes from [Core Workloads](https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads).

YCSB has 6 types of workloads. The main differences among each type are the portion of different operations.

1. Workload A: Update heavy workload
2. Workload B: Read mostly workload
3. Workload C: Read only
4. Workload D: Read latest workload
> In this workload, new records are inserted, and the most recently inserted records are the most popular. Application example: user status updates; people want to read the latest.
5. Workload E: Short ranges
> In this workload, short ranges of records are queried, instead of individual records. Application example: threaded conversations, where each scan is for the posts in a given thread (assumed to be clustered by thread id).
6. Workload F: Read-modify-write
> In this workload, the client will read a record, modify it, and write back the changes.
1. Workload A: `Update heavy workload`
2. Workload B: `Read mostly workload`
3. Workload C: `Read only`
4. Workload D: `Read latest workload`. In this workload, new records are inserted, and the most recently inserted records are the most popular. An application example is the user status updates and people want to read the latest.
5. Workload E: `Short ranges`. In this workload, short ranges of records are queried, instead of individual records. Application example: threaded conversations, where each scan is for the posts in a given thread (assumed to be clustered by thread ID).
6. Workload F: `Read-modify-write`. In this workload, the client will read a record, modify it, and write back the changes.

All six workloads have a data set which is **similar**. Workloads D and E insert records during the test run. Thus, to keep the database size consistent, we recommend the following sequence:
All 6 workloads above have a data set which is **similar**. Workloads D and E insert records during the test run. Thus, to keep the database size consistent, the following operation sequence is recommended:

1. Load the database, using workload A's parameter file (workloads/workloada) .
1. Load the database, using workload A's parameter file (workloads/workloada).

```sh
go-ycsb load -P workloads/workloada -p ...
go-ycsb load -P workloads/workloada -p ...
```

2. Run workload A (using workloads/workloada) for a variety of throughputs.

```sh
go-ycsb run -P workloads/workloada -p ...
go-ycsb run -P workloads/workloada -p ...
```

3. Run workload B (using workloads/workloadb) for a variety of throughputs.
4. Run workload C (using workloads/workloadc) for a variety of throughputs.
5. Run workload F (using workloads/workloadf) for a variety of throughputs.
6. Run workload D (using workloads/workloadd) for a variety of throughputs. This workload inserts records, increasing the size of the database.
7. Delete the data in the database.
> You need to destroy the cluster via `tiup cluster destroy [cluster-name]`, and delete the data directory of cluster. Otherwise, the remaining data of the cluster may impact the results of the following workload.
8. Start a new tikv cluster, load a new data set using workload E's parameter file (workloads/workloade).
7. Delete the data in the database. You need to destroy the cluster via `tiup cluster destroy [cluster-name]` and delete the data directory of cluster. Otherwise, the remaining data of the cluster might affect the results of the following workload.
8. Start a new TiKV cluster, load a new data set using workload E's parameter file (workloads/workloade).
9. Run workload E (using workloads/workloade) for a variety of throughputs. This workload inserts records, increasing the size of the database.

{{< info >}}
If you trying to use more clients to benchmark, check [Running a Workload in Parallel](https://github.com/brianfrankcooper/YCSB/wiki/Running-a-Workload-in-Parallel).
If you try to use more clients for benchmark test, see [Running a Workload in Parallel](https://github.com/brianfrankcooper/YCSB/wiki/Running-a-Workload-in-Parallel).
{{< /info >}}

For example, you can load a workload contains 10M records and 30M operations by:
For example, you can load a workload that contains 10 million records and 30 million operations by executing the following command:

```sh
go-ycsb load tikv -P workloads/workloada -p tikv.pd="10.0.1.1:2379" -p tikv.type="raw" -p recordcount=10000000 -p operationcount=30000000
```

After successfully loaded the data, you can launch it.
After the data is successfully loaded, you can launch the workload:

```sh
go-ycsb run tikv -P workloads/workloada -p tikv.pd="10.0.1.1:2379" -p tikv.type="raw" -p recordcount=10000000 -p operationcount=30000000
```

You can specify the concurrency of the workload client by `-p threadcount=`. Normally, the number should be the number of virtual CPU cores binded to the machine.
You can specify the concurrency of the workload client using `-p threadcount=`. Normally, this number should be the same as that of virtual CPU cores bound to the machine.

## Step 4. Inspect the benchmark results
## Step 4. Check the benchmark results

While running `go-ycsb`, it will reports workload runtime information like the OPS, latency:
While `go-ycsb` is running, the workload runtime information is output, such as the OPS and latency:

```
...
Expand All @@ -157,7 +158,7 @@ UPDATE - Takes(s): 9.7, Count: 110353, OPS: 11408.8, Avg(us): 7760, Min(us): 944
READ - Takes(s): 19.7, Count: 229147, OPS: 11647.2, Avg(us): 3094, Min(us): 202, Max(us): 342821, 99th(us): 52000, 99.9th(us): 58000, 99.99th(us): 335000
```

It will report the summary of the workload whlie the workload is done.
When the workload is completed, the summary of the workload is reported.

```
Run finished, takes 4m25.292657267s
Expand All @@ -166,24 +167,27 @@ UPDATE - Takes(s): 265.0, Count: 5001641, OPS: 18877.1, Avg(us): 5416, Min(us):
```
{{< warning >}}
If it report errors like `batch commands send error:EOF`, it relates to this [issue](https://github.com/pingcap/go-ycsb/issues/145).
If it reports an error like `batch commands send error:EOF`, refer to [this issue](https://github.com/pingcap/go-ycsb/issues/145).
{{< /warning >}}
## Step 5. Find the maximum throughput.
## Step 5. Find the maximum throughput
There are two way the find the maximal throughput of the TiKV cluster.
You can find the maximum throughput of the TiKV cluster in either of the following methods:
1. Increasing the threadcount of the client.
* You can increase the `threadcount` to the number of virtual cores of the machine. In some circumstances, it could reach the bottleneck of the TiKV cluster.
2. Increasing the count of benchmark clients.
* You can deploy more benchmark clients to increase the requests towards the TiKV cluster. Mutiple `go-ycsb` from different nodes could be launched simultaneously. And then you can summarise the result of these nodes.
+ Increase the `threadcount` of the client.
Repeat the 2 steps above, the bottleneck of the TiKV cluster is reached while the QPS showed in the TiKV cluster's Grafana page is no longer increasing.
You can increase the `threadcount` to the number of virtual cores of the machine. In some cases, the number might reach the bottleneck of the TiKV cluster.
## Step 6. Clean up
+ Increase the count of benchmark clients.
You can destroy the cluster by:
You can deploy more benchmark clients to increase the requests towards the TiKV cluster. Multiple `go-ycsb` from different nodes can be launched simultaneously. And then you can summarize the result of these nodes.
Repeat the 2 methods above. When the QPS displayed in the TiKV cluster's Grafana page is no longer increasing, the bottleneck of the TiKV cluster is reached.
## Step 6. Clean up the cluster
After the benchmark test is finished, you might want to clean up the cluster. To do that, run the following command:
```sh
tiup cluster destroy [cluster-name]
```
```
17 changes: 10 additions & 7 deletions content/docs/5.1/deploy/performance/overview.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ menu:
weight: 5
---


TiKV can deliver predictable throughput and latency at all scales on requiring hardware. This document provides an overview of TiKV benchmark performance on throughput and latency.

To learn how to reproduce the benchmark results in this document, see [Benchmark Instructions](./instructions.md). If you do not achieve similar results, check whether your hardware, workload, and test design meet the requirements in this document.
Expand Down Expand Up @@ -41,28 +41,31 @@ TiKV achieves this performance in [linearizability](https://en.wikipedia.org/wik
On a 3-node cluster of configuration listed above, TiKV can achieve 212,000 point get read per second on the YCSB workloadc and 43,200 update per second on the YCSB workloada. With different concurrencies, the throughput changes are shown in [Figure 1](https://docs.google.com/spreadsheets/d/e/2PACX-1vTIx695jjL3qYN1iR4xC3N8qh0B1qsHOALSBqf1B469b0DIZwVdzZMcSbBOOtAIo31hAdW0x_EXjmgq/pubchart?oid=1044850259&format=interactive).

{{< figure
src="/img/docs/ycsb-throughput.svg"
src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTIx695jjL3qYN1iR4xC3N8qh0B1qsHOALSBqf1B469b0DIZwVdzZMcSbBOOtAIo31hAdW0x_EXjmgq/pubchart?oid=1044850259&format=interactive"
caption="YCSB throughput"
width="1000"
number="1" >}}
number="1"
isIframe=true >}}

### Latency

TiKV is suitable for delay-sensitive services. Even at a high pressure throughput, the average latency is less than 10 ms, as shown in [Figure 2](https://docs.google.com/spreadsheets/d/e/2PACX-1vTIx695jjL3qYN1iR4xC3N8qh0B1qsHOALSBqf1B469b0DIZwVdzZMcSbBOOtAIo31hAdW0x_EXjmgq/pubchart?oid=334435174&format=interactive).

{{< figure
src="/img/docs/avg-latency.svg"
src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTIx695jjL3qYN1iR4xC3N8qh0B1qsHOALSBqf1B469b0DIZwVdzZMcSbBOOtAIo31hAdW0x_EXjmgq/pubchart?oid=334435174&format=interactive"
caption="YCSB latency"
width="1000"
number="2" >}}
number="2"
isIframe=true >}}

For the 99th percentile latency, see [Figure 3](https://docs.google.com/spreadsheets/d/e/2PACX-1vTIx695jjL3qYN1iR4xC3N8qh0B1qsHOALSBqf1B469b0DIZwVdzZMcSbBOOtAIo31hAdW0x_EXjmgq/pubchart?oid=6574505&format=interactive).

{{< figure
src="/img/docs/99-latency.svg"
src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTIx695jjL3qYN1iR4xC3N8qh0B1qsHOALSBqf1B469b0DIZwVdzZMcSbBOOtAIo31hAdW0x_EXjmgq/pubchart?oid=6574505&format=interactive"
caption="YCSB 99th percentile latency"
width="1000"
number="3" >}}
number="3"
isIframe=true >}}

## Performance limitations

Expand Down
17 changes: 13 additions & 4 deletions layouts/shortcodes/figure.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,21 @@
{{ if not $imgSrcSet }}
{{ errorf "You must set either an id or an src in the figure at content/%s" $.Page.File.Path }}
{{ end }}
{{ $src := cond (isset .Params "id") (printf "https://www.lucidchart.com/publicSegments/view/%s/image.png" (index .Params "id")) (index .Params "src" | relURL) }}
{{ $num := index .Params "number" }}
<figure>
{{ $src := cond (isset .Params "id") (printf "https://www.lucidchart.com/publicSegments/view/%s/image.png" (index .Params "id")) (index .Params "src" | relURL) }}
{{ $num := index .Params "number" }}
{{ $isIframe := index .Params "isIframe" }}

<figure class="{{ if $isIframe }}iframe-figure{{ end }}">
{{ if $isIframe }}
<div class="iframe-container">
<iframe seamless frameborder="0" src="{{ $src }}"></iframe>
</div>
{{ else }}
<a target="_blank" href="{{ $src }}">
<img src="{{ $src }}"{{ with (index .Params "alt") }} alt="{{ . }}"{{ end }}>
<img src="{{ $src }}" {{ with (index .Params "alt" ) }} alt="{{ . }}" {{ end }}>
</a>
{{ end }}

{{ with (index .Params "caption") }}
<figcaption class="is-size-3 is-size-4-mobile">
{{ with $num }}Figure {{ . }}. {{ end }}{{ . | markdownify }}
Expand Down

0 comments on commit b24e7f3

Please sign in to comment.