# memtier_benchmark

於 2013 年以 GPLv2 的授權形式發布，並於隔年 2014 年更新，除了基本的測試空能，新增隨機資料，且可以使用高斯分布去存取資料，以及限制資料大小範圍等功能。

2013 年: [memtier_benchmark: A High-Throughput Benchmarking Tool for Redis & Memcached](https://redis.io/blog/memtier_benchmark-a-high-throughput-benchmarking-tool-for-redis-memcached/)
2014 年: [New in memtier_benchmark: Pseudo-Random Data, Gaussian Access Pattern and Range Manipulation](https://redis.io/blog/new-in-memtier_benchmark-pseudo-random-data-gaussian-access-pattern-and-range-manipulation/)

## Reference

* [MICA: A Holistic Approach to Fast In-Memory Key-Value Storage](https://www.usenix.org/conference/nsdi14/technical-sessions/presentation/lim)
* [Benchmarking Cloud Serving Systems with YCSB](https://courses.cs.duke.edu/fall13/compsci590.4/838-CloudPapers/ycsb.pdf)

## Benchmark

### [Benchmarking Performance on Redis Enterprise and Google Cloud T2D Machines](https://redis.io/blog/redis-enterprise-google-cloud-t2d-benchmarks/)

#### 背景

Google 和 Redis 為了要測試 Redis 在 T2D Tau VMs 上的效能，所以寫了這篇文章。

#### 方法

在測試中使用的工具為 [PerfKit Benchmarker](https://googlecloudplatform.github.io/PerfKitBenchmarker/) (PKB) tool ，在 PKB 中有包含了多項效能測試工具，其中就有 Redis 自己開發的 memtier benchmark ，而 PKB 主要負責的工作就是管理雲端資源、程式庫的安裝、負載控制與測試完後的清理工作。

- [ ] 測試流程

* 建立伺服器與用戶端 VM
* 在伺服器端，建立 Redis 資料庫
* 在用戶端，安裝 memtier benchmark
* 用戶端先執行 memtier 以預先將資料載入資料庫 (preload)
* 在用戶端對伺服器進行負載測試
* 產出報告

- [ ] 測試指標

* Latency-capped Throughput (ops/sec): 測量在平均 1 ms 延遲下的最大吞吐量。
* Price-Performance (throughput/dollar): 以上述的吞吐量除以虛擬機器的價錢 (每小時多少錢) 。

#### 測試環境

##### 伺服器使用一台虛擬機器

不斷增加 CPU 數量，順序為 2, 4, 8, 16, 30/32

##### 伺服器叢集


#### 進行測試

先對資料庫用以下命令進行 preload ，這個命令預先載入大約 100 MB 的資料，對資料庫進行預先載入的原因是因為要降低 cache 對測試結果的影響。

memtier_benchmark -s localhost -a a9a204bb13 -p 12006 -t 1 -c 1 --ratio 1:0 --pipeline 100 -d 100 --key-pattern S:S --key-minimum 1 --key-maximum 1000000 -n allkeys --cluster-mode

預先載入結束後，接著調整執行緒的數量，直到平均延遲大於 1 ms ，超過這個數值之後，測試時紀錄吞吐量的最大值。

memtier_benchmark -s 10.240.6.184 -a a9a204bb13 -p 12006 -t 4 --ratio 1:1
--pipeline 9 -c 24 -d 100 --key-minimum 1 --key-maximum 1000000 -n 1000000
--cluster-mode

### [Optimizing Redis’ Default Compiler Flags](https://redis.io/blog/optimizing-redis-compiler-flags/)

#### 背景

Redis 與 Intel 想要測試在不同編譯器以及編譯最佳化參數下，對 Redis 效能的影響，分別使用 GCC 9.4 、 GCC 11 和 Clang-14 進行測試。

#### 方法

使用 [performance automation framework](https://redis.io/blog/redis-intel-performance-testing/) 這套框架進行測試，以及對應的 [Redis Benchmarks Specification](https://github.com/redis/redis-benchmarks-specification/) ，提供自動化測試效能以及其他指標的功能，並且測試支援 memtier_benchmark 。


### [Comparing the new Redis6 multithreaded I/O to Elasticache & KeyDB](https://docs.keydb.dev/blog/2020/04/15/blog-post/)

#### 背景

比較 Elasticache 、 KeyDB 與 Redis 的效能。 KeyDB 將事件循環放在多個執行緒中，以並行處理網路 I/O 與來自用戶端的請求。

#### 方法

使用 Yahoo 開發的 [YCSB](https://github.com/brianfrankcooper/YCSB) 分別以不同的負載進行測試。

* 讀寫比例 1:1
* 讀寫比例 95:1
* 只有讀取
* 只讀取最近放入資料庫中的資料

還有其他種負載測試資料集，可以參考[詳細資料](https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads)。

除了測量吞吐量與延遲，最後還有輸出 [Flame Graph](https://github.com/brendangregg/FlameGraph) ，了解程式的瓶頸。

### [Redis Analysis - Part 1: Threading model](https://www.dragonflydb.io/blog/redis-analysis-part-1-threading-model)

#### 背景

社群上不停爭論 Redis 是否應該要是多執行緒，並提供水平擴展與垂直擴展的差異。

#### 方法

測試前，使用命令 `debug populate 10000000` 將資料放入伺服器，並且在執行 memtier_benchmark 時，只執行讀取的命令，參數如下 `--key-prefix=key: --key-pattern=P:P --ratio 0:1 -n 2000000` ，並且調整 memtier_benchmark 的執行緒與連線數量。
另外在上述條件下，分別進行兩次測試，第一次沒有使用 `--pipeline` 參數，第二次加上 `--pipeline 10` ，比較兩種實驗結果。

### [Redis vs. Dragonfly Scalability and Performance](https://www.dragonflydb.io/blog/scaling-performance-redis-vs-dragonfly)

#### 背景

如文章所說， Redis 的垂直擴展能力較差，為了解決這項問題，推出 Dragonfly ，所以為了比較這兩者的差異才進行了這次測試。

#### 方法

測試吞吐量，使用 `debug populate 100000000 key 500` 預先載入資料，模擬正在使用的情境，測試時使用以下的命令。

memtier_benchmark -p 6380 --ratio=<1:0 for GET, 0:1 for SET> --hide-histogram --threads=<2 for Redis, 64 for Dragonfly> --clients=30 --requests=200000 --distinct-client-seed --data-size 256 --expiry-range=500-500 -s <IP address for Redis/Dragonfly server>

### [A High Performance Memory Key-Value Database Based on Redis](http://www.jcomputers.us/vol14/jcp1403-03.pdf)

#### 背景

這篇論文主要介紹中國公安部第一研究所開發的 Redis++ ，並與 Redis 4.0.6 比較。

#### 方法

根據 Meta 的論文 [Workload Analysis of a Large-Scale Key-Value Store](https://research.facebook.com/publications/workload-analysis-of-a-large-scale-key-value-store/) ，他們統計了正在 production 的 Memcached 叢集，發現大部分的 key 都不會超過 100 bytes ，且有 95% 的 value 大小都小於 1024 byte ，所以，設計以下三種資料集，分為小中大三種。

| Scale | Key (Bytes) | 95% Value (Bytes) | 5% Value (Bytes) |
|:-----:|:-----------:|:-----------------:|:----------------:|
| Tiny | 8 | 8 - 16 | 1024 - 10240 |
| Small | 16 | 16 - 128 | 1024 - 10240 |
| Large | 128 | 128 - 1024 | 1024 - 10240 |

測試延遲，每次測試只執行一個用戶端，並發送 1000000 次請求，進行多次實驗後取平均，測試資料為上述三種資料集。


測試吞吐量，使用的工具為 [YCSB](https://github.com/brianfrankcooper/YCSB) ，分為兩種測試場景，第一種為讀寫比例 1:1 ，第二種為讀寫比例 95:5 ，另外，對 key 的生成也分為兩種，一種是 Unif ，也就是隨機生成，但每一種 key 生成機率相同，另外一種是 Zipf ，根據 Ziff 分布來生成 key ，分別在三種資料集上進行測試。


### [Segcache: a memory-efficient and scalable in-memory key-value cache for small objects](https://www.usenix.org/conference/nsdi21/presentation/yang-juncheng)

#### 背景

介紹 CMU 開發的 Segcache ，並與 Memcached 等 in-memory cache 做比較。

#### 方法

使用 Twitter 中真實的用戶資料當作測試資料集。


對吞吐量與擴展性進行測試，擴展性為將執行緒數量從 1 - 24 依次提高。

## [Benchmarking Cloud Serving Systems with YCSB](https://github.com/brianfrankcooper/YCSB/wiki/Papers-and-Presentations)

### Introduction

YCSB 這個框架包含了產生 workload 的 client ，還有包含各種效能測試資料的 package ，這個框架強調擴充性，可以很容易的自訂資料集還有 workload ，或是整合其他種資料庫。

### Benchmark Tiers

#### Tier 1 - Performance

延遲和吞吐量之間的取捨是很早以前就存在的，當負載增加時，單一請求的延遲也會增加，因為對 CPU 、網路等資源有更多的競爭。在效能測試中，最主要的目的是要測量取捨的程度，測量延遲的同時增加吞吐量，直到吞吐量不再增加，這個方法與在 Wisconsin Benchmark 中的 sizeup 類似，在硬體資源不變的情況下增加負載。

#### Tier 2 - Scaling

論文中指的是在機器數量增加的情況下，資料庫的表現如何，在我們的情境中，可以改成在執行緒數量增加的情況下， 多執行緒的 Valkey 表現如何，如果資料庫有良好的擴展性，效能表現必須要是一個常數，例如延遲等數據，當硬體資源增加時，吞吐量也要跟著增加。

### Benchmark Workload

每一種 workload 代表特定比例的 read/write 操作、資料大小與請求分布組合而成，使用者可以使用新的參數或是撰寫 Java 程式碼自訂想要的 workload 。

#### Distributions

* Uniform: 在請求資料庫中的資料時，所有的資料被取得的機率都大致相同。
* Zipfian: 某些資料的請求頻率特別高，有些特別低，但沒有指定哪一種資料的請求會特別高。
* Latest: 是 Zipfian 分布的特化版，也是有些資料被請求的機率特別高，但是指定是最近剛加入資料庫中的資料。


### Benchmark Tool

這個框架強調擴展性，必須讓使用者可以加入新的資料庫種類，或是新增自定義的 workloads ， YCSB client 由幾個部分組成， workload executor 驅動 client 執行緒，每一個執行緒都會呼叫資料庫的 interface ，包含載入資料階段與執行 workload 階段。


## Problem

* 測試前預先載入資料，將 cache 的影響減至最小，要載入什麼樣的資料?
* Ans: `ycsb load`
* YCSB 與 memtier_benchmark 不同的地方?
* Ans: 更多可以自訂的選項，像是可以自己決定插入或是讀取要做什麼動作，或是自訂產生資料集的方法。
* 資料集的設計參考 [Workload Analysis of a Large-Scale Key-Value Store](https://research.facebook.com/publications/workload-analysis-of-a-large-scale-key-value-store/) 這篇論文
* Ans: GET:SET 比例 30:1 、 GET:SET 比例 1:1 、 GET:SET 極端比例 95:5