kevy 6.3.0 · 基准测试

有多快，以及哪里不快

一台机器，16 核，loopback。每一个数字都能用仓库里的 bench/ 复现。做任何决定之前，先把最后两行读完——在那两行上，性能并不构成换过来的理由。

四个引擎，一台机器

50 条连接，小 value。五次运行取中位数，数字取自每个服务端自己的命令计数器，统计的是三秒稳态窗口内的增量，而不是压测客户端报出来的速率。

	kevy 6.3.0	Redis 8.10.1	valkey 9.1.2	Dragonfly 1.40.2	vs Redis 8.10.1
GET	7,489,119	5,631,398	2,980,764	2,845,704	*1.33×
SET	6,824,662	2,567,607	1,683,227	1,943,358	*2.66×
INCR	6,753,558	3,294,927	2,279,738	1,953,406	*2.05×
SADD	6,152,617	3,753,131	2,214,659	1,899,967	*1.64×
HSET	4,002,580	2,966,288	1,857,532	1,773,498	*1.35×
LPUSH	3,142,699	2,860,306	1,859,265	1,505,141	!1.10×
ZADD	3,242,967	2,818,626	1,786,230	1,794,335	!1.15×

LPUSH 比 Redis 8.10.1 快 10%，ZADD 快 15%。差距只有这么大的时候，决定胜负的是你的 value 大小和 key 分布，而不是引擎——所以如果 list 或者 sorted set 是你的热路径，请拿你自己的负载去测，不要为了性能而换。这两行的颜色是故意标成这样的。

这组数字没有告诉你的事

这是 loopback。这里没有网络，而在真实部署里，你等的往往正是网络。如果你的延迟大部分花在网络上，那么一个 GET 快 2.6× 的引擎，并不会让你的 p99 也好 2.6×。

value 很小。一个 value 到 64 KB 的时候，整件事的瓶颈会落到内核的 TCP 路径上，差距收窄到个位数百分比。如果你存的是大块数据，这些数字说的不是你。

这是一台机器。kevy 没有集群模式。如果你的问题是一台机器不够用，这一页上没有任何数字帮得上忙。

浏览器构建产物

你真正会发到标签页里的东西。

	体积
kevy.wasm	1442 KB	引擎本体，未压缩
gzip 之后	481 KB	真正过网络的量
冷启动	< 20 ms	编译加实例化，缓存已热

做一次小的同步读，localStorage 比 kevy 快，而且永远会更快——它就是页面自己地址空间里的一个 map。kevy 赢的是那些本来就让 localStorage 不该被用的地方：真的 TTL、没有 5 MB 上限、value 是字节而不是字符串、写入不挡主线程。

自己复现

git clone https://github.com/goliajp/kevy && cd kevy

# four-way: kevy, Redis 8, valkey, Dragonfly
bash bench/arena.sh

# the regression gate CI runs on every push
bash bench/perfgate.sh

两个脚本。这一页上的所有东西都是它们跑出来的。