一台机器，16 核，loopback。每一个数字都能用仓库里的 bench/ 复现。做任何决定之前，先把最后两行读完——在那两行上，性能并不构成换过来的理由。
50 条连接，pipeline 16，小 value，每个引擎 4 核。取 15 个窗口（3 轮，每轮 5 个）的中位数，数字取自每个服务端自己的命令计数器在三秒窗口内的增量，而不是压测客户端报出来的速率。带 ≥ 的数字是压测端喂不满时的读数，引擎至少有这么快；竞品的这种数字不算倍数。
| kevy 7.0.0 | Redis 8.10.2 | valkey 9.1.2 | Dragonfly 2.0.0 | vs Redis 8.10.2 | |
|---|---|---|---|---|---|
| GET | 8,726,283 | 5,467,748 | 4,041,855 | ≥ 3,364,079 | *1.60× |
| SET | ≥ 7,409,590 | 2,861,941 | 2,011,380 | 2,019,740 | *≥ 2.59× |
| INCR | 7,249,946 | 3,788,318 | 2,750,827 | 2,223,491 | *1.91× |
| SADD | 6,919,570 | 4,204,106 | 2,728,331 | 1,911,038 | *1.65× |
| HSET | ≥ 5,393,670 | 3,352,393 | 2,283,589 | 1,964,211 | *≥ 1.61× |
| LPUSH | 4,424,738 | 3,220,774 | 2,260,722 | 1,700,519 | *1.37× |
| ZADD | ≥ 4,980,252 | 3,112,253 | 2,159,811 | 1,804,781 | *≥ 1.60× |
LPUSH 比 Redis 8.10.2 快 37%，是领先最少的一行。差距这么小的时候，你的 value 大小和 key 分布跟引擎一样重要——所以如果 list 是你的热路径，为了性能换过来之前，请拿你自己的负载去测。
这是 loopback。这里没有网络，而在真实部署里，你等的往往正是网络。如果你的延迟大部分花在网络上，那么一个 GET 快 2× 的引擎，并不会让你的 p99 也好 2×。
value 很小。一个 value 到 64 KB 的时候，整件事的瓶颈会落到内核的 TCP 路径上，差距收窄到个位数百分比。如果你存的是大块数据，这些数字说的不是你。
这是一台机器。kevy 没有集群模式。如果你的问题是一台机器不够用，这一页上没有任何数字帮得上忙。
你真正会发到标签页里的东西。
| 体积 | ||
|---|---|---|
| kevy.wasm | 1865 KB | 引擎本体，未压缩 |
| gzip 之后 | 639 KB | 真正过网络的量 |
| 冷启动 | < 20 ms | 编译加实例化，缓存已热 |
做一次小的同步读，localStorage 比 kevy 快，而且永远会更快——它就是页面自己地址空间里的一个 map。kevy 赢的是那些本来就让 localStorage 不该被用的地方：真的 TTL、没有 5 MB 上限、value 是字节而不是字符串、写入不挡主线程。
git clone https://github.com/goliajp/kevy && cd kevy
cargo build --release -p kevy
# four-way: kevy, Redis 8, valkey, Dragonfly
bash bench/arena.sh target/release/kevy
# two kevy builds side by side: the last release against this tree
bash bench/perfgate.sh compare last-release HEAD两个脚本。这一页上的所有东西都是它们跑出来的。