基準環境

• 機器：AWS EC2 c4.8xlarge（同機部署 Redis Server 與 ReJSONBenchmark 工具，通過網絡棧連接）
• 測試工具：ReJSONBenchmark（Go 實現、可配置并發）
• 模式：非管線（non-pipelined）
• 版本：RedisJSON Preview（尚未完全優化）

基線對比：PING

工具	并發	吞吐 (req/s)	平均延遲 (ms)	99% 延遲 (ms)
redis-benchmark	50	140,587	≤1	≤1
ReJSONBenchmark	16	116,292	0.14	0.21

洞察：Go 測試工具在 PING 下吞吐略低于 redis-cli，但延遲依舊亞毫秒級。

JSON 操作性能

測試場景	操作	吞吐 (req/s)	平均延遲 (ms)
空字符串（2B）	JSON.SET / JSON.GET	80,277 / 92,191	0.20 / 0.17
小對象（380B, pass-100.json）	SET 根 / GET 根	41,513 / 48,374	0.38 / 0.33
	GET 標量路徑	94,801	0.17
	GET 子文檔	81,634	0.19
中等數組（1.4 KB）	SET 根 / GET 根	16,117 / 15,194	0.99 / 1.05
	GET 元素 / 子字段	78K–99K	~0.20
大對象（3.5 KB）	SET 根 / GET 根	14,239 / 8,366	1.12 / 1.91
超大文檔（18 KB / 40 KB）	SET 根 / GET 根 (18 KB)	3,394 / 891	4.71 / 17.92
	SET 根 / GET 根 (40 KB)	1,625 / 443	9.84 / 36.08
數值運算	NUMINCRBY / NUMMULTBY	78,640 / 77,171	~0.20

結論：

• 文檔越小，吞吐越高、延遲越低；
• 部分路徑操作（標量、子文檔）性能遠超訪問整個根文檔；
• 數值原子操作也能保持 >77K req/s 的高吞吐。

與 Server-Side Lua 腳本對比

• 根級 SET/GET：RedisJSON、Lua(cjson/cmsgpack) 性能相近（80–90K req/s）。

• 路徑級 SET/GET：

  • RedisJSON：直接內存訪問，無需整體解碼，保持 >75K req/s 且延遲穩定；
  • Lua：每次都解碼整個對象，隨著文檔增大性能急劇下降（大文檔時 <20K req/s）。

洞察：RedisJSON 原生命令在局部更新/讀取場景下，解碼與操作開銷大幅低于基于腳本的實現。

小結

1. 極低延遲：空字符串與小對象下，延遲普遍 <0.2 ms。
2. 高吞吐量：簡單路徑查詢可達 ~100K req/s；數值運算也能維持 >75K req/s。
3. 可擴展性：文檔體量增大時，根級操作延遲線性上升，但仍可滿足毫秒級需求；部分路徑訪問保持亞毫秒穩定。
4. 優于腳本：相比 Lua 全文解碼，RedisJSON 的“就近解碼”帶來顯著性能與資源優勢。

通過本次基準，我們可以清晰看到 RedisJSON 在不同載荷與操作模式下的性能特性，為生產環境評估提供了可靠參考。