数据库安全后端【免费下载链接】immudbimmudb - immutable database based on zero trust, SQL/Key-Value/Document model, tamperproof, data change history项目地址https://gitcode.com/gh_mirrors/im/immudb点击查看免费下载导读immudb 性能测试套件test/performance-test-suite是 immudb 项目自带的性能分析工具用于在各种真实工作负载下检验 immudb 的性能表现。它由两大部分组成负责压测与结果输出的perf-test读写基准生成器 运行器以及负责基准对比与回归门禁的perf-delta增量对比工具。阅读本文后你将掌握如何构建并运行短/长两种性能测试、如何解析 JSON 结果的时间线与汇总数据、如何配置 InfluxDB 集中存储结果以及如何利用perf-delta在 CI 中自动拦截性能回归。一、套件定位与整体架构该套件是 immudb 的主要性能分析工具其核心目标是用真实世界负载而非微基准检验 immudb 的性能。从源码结构看它由三个层级组成test/performance-test-suite/ ├── cmd/ │ ├── perf-test/ # 压测入口执行全部基准并输出 JSON 结果 │ │ └── main.go │ └── perf-delta/ # 对比两个 JSON 结果报告性能增量/回归 │ ├── main.go │ └── main_test.go └── pkg/ ├── benchmarks/ # 基准抽象与通用工具 │ ├── benchmark.go # Benchmark 接口 │ ├── format.go # 数值格式化 │ ├── hwstats.go # 硬件/系统统计采集 │ ├── keytracker.go # 键生成器含 Zipf 分布 │ ├── rand.go # 随机字符串生成器 │ ├── readtxs/ # 读基准Get/s │ │ └── benchmark.go │ └── writetxs/ # 写基准TX/s、KV/s │ └── benchmark.go └── runner/ # 运行调度、结果结构、系统信息与 InfluxDB 上报 ├── benchmarks.go ├── influxdb_client.go ├── processinfo.go ├── results.go ├── runner.go └── systeminfo.go套件由perf-test入口驱动runner.RunAllBenchmarks依次执行注册在 getBenchmarksToRun 中的基准最终通过BenchmarkSuiteResult结构输出到 stdout形成一份 JSON 报告详见后文“输出格式”。二、短测试与长测试Long vs short runREADME 明确指出测试规模是可配置的套件区分两种运行模式模式定位使用场景短测试short快速性能测试每次 immudb push 到 master 分支时执行长测试long完整性能回归测试每个 release 发布前必须执行确保无性能回退默认模式是短性能测试。两种模式在代码层面的差异体现在运行时长参数-d上perf-test的-d标志控制每个基准的持续时长默认值为 10 秒main.go。CI 与发布流程只需要传入不同的时长即可切换模式。一个值得注意的工程细节写基准的Run方法通过time.After(duration)与done通道协同在时间到点后优雅关闭所有 worker goroutine见 writetxs/benchmark.go避免Cleanup与仍在途的SetAll调用产生竞态——这也是从源码中可以观察到的稳定性设计。三、输出格式时间线 汇总 系统元数据README 说明套件产生一个包含性能详细信息的 JSON 输出文件内容包括整个测试期间的各项测量时间线timeline汇总summary尽可能采集的底层系统元数据用于不同系统之间的对比。3.1 JSON 顶层结构顶层结构由 results.go 中的BenchmarkSuiteResult定义{ startTime: ..., endTime: ..., duration: ..., processInfo: { commandLine: [], version: , gitCommit: , builtBy: , builtAt: }, systemInfo: { hostname: }, benchmarks: [ { name: Write TX/s async - no replicas, summary: TX: 1234, KV: 1234, TX/s: 123.45, KV/S: 12345.67, startTime: ..., endTime: ..., duration: ..., requestedDuration: ..., results: { txTotal: 1234, kvTotal: 1234, txs: 123.45, kvs: 12345.67, hwStats: { } }, timeline: [ { time: ..., duration: ..., probe: { } } ] } ] }3.2 时间线Timeline与探针Probe每个基准运行期间runner.RunAllBenchmarks会启动一个每秒触发一次的探针 goroutine周期性调用Benchmark.Probe()并记录BenchmarkTimelineEntryrunner.go。时间线条目由 results.go 定义time探针采集时刻duration距离基准启动的累计时长probe该时刻的瞬时性能快照。以写基准为例探针返回的Result除了累计的TxTotal/KvTotal与平均Txs/Kvs之外还会计算自上次探针以来的瞬时速率TxsInst/KvsInst见 writetxs/benchmark.go。因此时间线能反映性能随时间的波动例如冷启动、缓存升温、副本复制压力等而不仅是最终平均速率。3.3 系统元数据BenchmarkSuiteResult同时携带processInfo命令行、版本、Git 提交、构建者、构建时间来自 processinfo.go与systemInfo主机名来自 systeminfo.go。硬件统计由 hwstats.go 通过 Prometheusprocfs库采集HWStats字段包含字段JSON 键含义CPUTimecpuTime进程累计 CPU 时间秒CPUKernelTimeFractioncpuTimeKernelFraction内核态 CPU 时间占比VMMvmm虚拟内存用量RSSrss常驻内存用量IOBytesRead / IOBytesWriteioBytesRead/ioBytesWrite读/写字节数IOCallsRead / IOCallsWriteioCallsRead/ioCallsWrite读/写系统调用次数这些元数据正是“用于不同系统之间对比”的基础——同一版本在不同硬件上的结果可以通过 CPU/内存/IO 指标解释差异。3.4 时间戳序列化为人类可读格式runner.Duration是time.Duration的包装类型其MarshalJSON将纳秒级时长序列化为 Go 的time.Duration字符串如10s、1m2.3s保证 JSON 可读且可直接比较results.go。四、基准集合写路径与读路径getBenchmarksToRun返回的基准集合分为写与读两大阵营benchmarks.go。4.1 写基准writetxs写基准通过writetxs.Config配置覆盖 TX/s 与 KV/s 两个度量维度、同步/异步写两种模式、以及无副本/一个异步副本/一个同步副本三种拓扑配置含义Workers并发客户端数量套件固定为 30BatchSize每个SetAll请求携带的 KV 数1 单 KV 事务1000 批量KeySize键长度默认 32键由sha256生成后截断ValueSize值长度默认 128随机字符串AsyncWrite是否异步写NoWait标志对应schema.SetRequest.NoWaitReplica空 /async/sync决定是否拉起副本及复制模式由此组合出的基准名称包括Write TX/s async - no replicas30 workers、batch1、异步、无副本Write KV/s async - no replicas30 workers、batch1000、异步、无副本Write TX/s async - one async replica/Write KV/s async - one async replicaWrite TX/s async - one sync replica/Write KV/s async - one sync replicaWrite TX/s sync - no replicas/Write KV/s sync - no replicasWrite TX/s sync - one async replica/Write KV/s sync - one async replicaWrite TX/s sync - one sync replica/Write KV/s sync - one sync replica其中“同步复制 1 个同步 ACK”WithSyncReplication(true).WithSyncAcks(1)与“异步复制”分别对应 replication 管线中的不同提交语义。每个写基准在Warmup阶段会以嵌入式方式就地启动一个 immudb 服务server.DefaultOptions()WithPort(0)随机端口并关闭 Web/Metrics/PgSQL 端口随后为每个 worker 打开一个客户端会话writetxs/benchmark.go。复制拓扑则由一个指向主库的副本服务实现副本选项包含PrimaryHost、PrimaryPort、PrefetchTxBufferSize1000、ReplicationCommitConcurrency30等。4.2 读基准readtxs读基准是写基准的读侧对偶模拟现实工作负载的局部性。其配置包含KeyPopulation预热键总数与 Zipf 分布参数ZipfS/ZipfVreadtxs/benchmark.go配置含义KeyPopulationWarmup 阶段预置的键总数当前为 100,000ZipfS偏斜度1.1 ≈ 接近均匀2.0 ≈ 极强偏斜大多数读命中顶部约 1% 的键0 退化为均匀分布ZipfVZipf 分布的 v 参数当前为 1当前套件内置两个读基准Read Get/s zipf (s1.5) - 100k key population热集行为——少数“热键”占据大部分读流量贴近真实负载Read Get/s uniform - 100k key population缓存最差情况——每次读都可能未命中。readtxs包注释明确指出均匀随机读会掩盖缓存与索引效应而热集读则相反两者共享同一KeyPopulation保证内部存储的驻留集压力可比。在Warmup阶段读基准会用首个客户端以每批 1000 个键的方式预置 10 万键分批是为了保持在MaxTxEntries限制内随后在Run阶段并发发出Get请求结果字段为getTotal/gets/getsInstantreadtxs/benchmark.go。五、运行性能测试命令行参数与示例5.1 perf-test 命令参数perf-test的命令行参数定义在 cmd/perf-test/main.go参数默认值说明-d10s每个测试运行的时长-s0数据生成器种子-random-seedfalse为 true 时使用随机种子从crypto/rand读取 8 字节生成-hostInfluxDB 地址 URL-tokenInfluxDB token-bucketimmudb-tests-resultsInfluxDB bucket 名-runnerInfluxDB 上报用的 runner 标识如 GitHub runner 名-versionInfluxDB 上报用的 immudb 版本号-workdir/tmp工作目录路径嵌入式服务与客户端临时目录的基目录5.2 运行示例短测试默认 10 秒/基准cd test/performance-test-suite go run ./cmd/perf-test results.json固定种子以便结果可复现go run ./cmd/perf-test -d 30s -s 42 results-short-30s.json随机种子 长测试发布前回归检查go run ./cmd/perf-test -d 5m -random-seed results-long.json长测试建议直接重定向保存 JSONgo run ./cmd/perf-test -d 1h results-release.json5.3 运行期间的日志输出runner会输出每个基准的进度与探针快照格式形如Starting immudb performance test suite Running benchmark: Write TX/s async - no replicas [Write TX/s async - no replicas] 5s/10s TX: 1234, KV: 1234, TX/s: 123.45, KV/S: 12345.67 Benchmark Write TX/s async - no replicas finished Results: TX: 1234, KV: 1234, TX/s: 123.45, KV/S: 12345.67 Finished immudb performance test suite其中每秒钟的探针行正是 JSONtimeline的实时体现。六、结果集中存储InfluxDB 集成README 指出目前性能测试结果仅附加在 CI 输出上未来规划建立集中存储以长期积累所有结果。不过代码中已经实现了 InfluxDB 上报通道只要在命令行同时提供-host、-token、-runner、-version四个参数perf-test在输出 JSON 后就会调用runner.SendResultsToInfluxDbcmd/perf-test/main.go。上报逻辑位于 influxdb_client.go它使用官方 influxdb-client-go 创建客户端向 orgCodenotary、bucket默认immudb-tests-results写入performance测量点每条时间序列携带name基准名、runner、version标签字段包括duration、txTotal/kvTotal/txs/kvs写基准、getTotal/gets读基准以及共享的硬件统计字段cpuTime、vmm、rss、IOBytesRead、IOBytesWrite、IOCallsRead、IOCallsWrite。示例go run ./cmd/perf-test \ -host http://influxdb.example.com:8086 \ -token $INFLUX_TOKEN \ -bucket immudb-tests-results \ -runner github-runner-01 \ -version v1.4.0结合 Grafana 等可视化工具仓库根目录 tools/monitoring/grafana-dashboard.json 提供现成 dashboard即可把immudb-tests-results中的数据绘制成性能趋势图逐步向“集中存储 长期对比”的目标演进。七、性能回归门禁perf-delta 增量对比工具7.1 用途与用法perf-delta用于对比两份perf-test生成的 JSON 结果文件按基准逐一报告 TX/s 与 KV/s 的增量变化当任一基准的退化幅度超过配置的容差时以非零退出码结束因此可直接作为 CI 回归门禁使用perf-delta/main.go。go run ./cmd/perf-delta \ -baseline baseline.json \ -current current.json \ -tolerance 0.057.2 参数说明参数默认值说明-baseline基线性能结果 JSON 路径必填-current当前性能结果 JSON 路径必填-tolerance0.05每个指标允许的最大相对退化比例0.05 5%7.3 输出与退出语义perf-delta输出稳定的 Markdown 表格可直接附加到 PR 评论| Benchmark | Baseline TX/s | Current TX/s | Δ TX/s | Baseline KV/s | Current KV/s | Δ KV/s | |-----------|--------------:|-------------:|-------:|--------------:|-------------:|-------:| | Write TX/s async - no replicas | 1000.00 | 950.00 | -5.00% ❌ | 50000.00 | 49000.00 | -2.00% |当前结果中存在但基线中没有的基准标记为(new / not in baseline)基线中存在但当前缺失的基准标记为(missing in current)并累计missingCurr任一基准的 TX/s 或 KV/s 退化 ≤-tolerance默认 -5%时标记 ❌ 并计入regressions末尾输出N regression(s) beyond X% tolerance; M benchmark(s) missing in current.只要存在回归regressions 0进程以退出码 1 结束否则正常退出perf-delta/main.go。7.4 关键实现细节增量计算delta(base, curr) (curr - base) / base基线为 0 时返回 0避免空基线把所有基准误判为回归或提升perf-delta/main.go。前向兼容工具只解码所需字段name、results.txs、results.kvs对结果格式的新增字段保持稳定perf-delta/main.go。测试保障main_test.go 覆盖了增量计算的边界情形相同值、±5% 增益/损失、零基线以及 JSON 加载的成功/失败路径文件缺失、非法 JSON。八、CI 集成建议组合短测试 回归门禁将两个工具串联即可实现 README 描述的“push 到 master 即跑短测试”流程# 1. 跑短测试并保存结果 go run ./cmd/perf-test -d 10s current.json # 2. 与上一轮基线的短测试结果对比5% 容差 go run ./cmd/perf-delta -baseline previous.json -current current.json -tolerance 0.05若上一步返回非零退出码CI 即标记该 push 存在性能回归。发布前再执行长测试-d设为小时级并人工审阅 JSON 时间线与硬件元数据。九、小结immudb performance test suite 提供了一个从“压测”到“回归门禁”的完整闭环短/长双模式通过-d调节测试规模短测试守护日常 push长测试把关每个 release真实负载建模30 并发 worker、同步/异步写、无/异步/同步副本拓扑、Zipf 热集读与均匀读覆盖写入吞吐TX/s、KV/s与读取吞吐Get/s两大类指标丰富输出JSON 同时包含逐秒时间线、汇总、进程/系统元数据与硬件统计便于跨系统对比集中存储通道InfluxDB 上报已就绪为未来集中结果库和长期趋势分析打下基础回归门禁perf-delta以 Markdown 表格输出增量并以非零退出码拦截超过容差默认 5%的性能退化可直接嵌入 CI。若需要深入各基准的底层实现嵌入式服务启动、复制选项、Zipf 键跟踪器可继续研读 writetxs/benchmark.go、readtxs/benchmark.go 与 runner.go。赞分享数据库安全后端【免费下载链接】immudbimmudb - immutable database based on zero trust, SQL/Key-Value/Document model, tamperproof, data change history项目地址https://gitcode.com/gh_mirrors/im/immudb点击查看免费下载相关推荐cuML Benchmark Suite 完整指南从命令行基准测试到 YAML 回归套件cuML Benchmark Suite 完整指南从命令行基准测试到 YAML 回归套件 cuML 是 NVIDIA 推出的 GPU 加速机器学习库其内置的机器学习高性能计算whichllm 为你的显卡挑出最好的本地大模型whichllm 为你的显卡挑出最好的本地大模型 whichllm 是一款本地 LLM 推荐工具。你不用自己算显存也不用逐个翻榜单它扫一眼你的硬件就给出该人工智能大模型本地部署CLIruflo 基准测试套件Benchmark SuiteAgent 深度解析性能基准、回归检测与验证框架实战ruflo 基准测试套件Benchmark SuiteAgent 深度解析性能基准、回归检测与验证框架实战 导读 ruflo原 claude flow人工智能AI Agent多智能体Agent 编排Agent 记忆工具调用代码智能体MCP 服务AI 评测上一篇Docusaurus 站点构建与部署实战从 npm run build 到 Vercel 零配置上线下一篇Nx 迁移机制实战自动将 dev.nx.gradle.project-graph 插件升级到 0.1.8创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
