memtier_benchmark

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

2013 年: memtier_benchmark: A High-Throughput Benchmarking Tool for Redis & Memcached
2014 年: 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
• Benchmarking Cloud Serving Systems with YCSB

Benchmark

Benchmarking Performance on Redis Enterprise and Google Cloud T2D Machines

背景

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

方法

在測試中使用的工具為 PerfKit Benchmarker (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

背景

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

方法

使用 performance automation framework 這套框架進行測試，以及對應的 Redis Benchmarks Specification ，提供自動化測試效能以及其他指標的功能，並且測試支援 memtier_benchmark 。

Comparing the new Redis6 multithreaded I/O to Elasticache & KeyDB

背景

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

方法

使用 Yahoo 開發的 YCSB 分別以不同的負載進行測試。

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

還有其他種負載測試資料集，可以參考詳細資料。

除了測量吞吐量與延遲，最後還有輸出 Flame Graph ，了解程式的瓶頸。

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

背景

如文章所說， 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

背景

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

方法

根據 Meta 的論文 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 ，分為兩種測試場景，第一種為讀寫比例 1:1 ，第二種為讀寫比例 95:5 ，另外，對 key 的生成也分為兩種，一種是 Unif ，也就是隨機生成，但每一種 key 生成機率相同，另外一種是 Zipf ，根據 Ziff 分布來生成 key ，分別在三種資料集上進行測試。

Segcache: a memory-efficient and scalable in-memory key-value cache for small objects

背景

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

方法

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

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

Benchmarking Cloud Serving Systems with YCSB

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 這篇論文
  • Ans: GET:SET 比例 30:1 、 GET:SET 比例 1:1 、 GET:SET 極端比例 95:5