Hono HTTP Benchmark 使用指南用 bombardier 对比 main 与当前分支的 HTTP 性能【免费下载链接】honoWeb framework built on Web Standards项目地址: https://gitcode.com/GitHub_Trending/ho/hono本指南基于 Hono 仓库中的 benchmarks/http-server/README.md 及其配套实现 benchmarks/http-server/benchmark.ts系统讲解 Hono 官方 HTTP 性能基准测试工具的设计思路、运行方式与结果解读。读完本文你将掌握如何在本机一键对比main分支与当前工作区的 HTTP 吞吐差异理解测试场景、命令行参数与底层执行流程并能在提交 Pull Request 前自行复现同样的性能评估。工具定位它测的是什么Hono HTTP Benchmark 是一套面向 HTTP 层面的性能基准测试脚本核心目标只有一个对比main分支与当前代码两个版本的 Hono 在真实 HTTP 请求下的吞吐表现。它属于端到端式压测——通过 bombardier 这类负载工具向真实启动的服务器发送并发请求衡量整体处理能力。它与仓库中的另一套基准测试 benchmarks/fetch/README.mdfetch benchmark形成互补fetch benchmark在进程内直接调用app.fetch()衡量的是框架路由与响应构造本身的 CPU 开销纳秒级HTTP benchmark通过真实的 TCP 连接发起并发 HTTP 请求衡量的是包含运行时Bun、HTTP 解析、响应序列化在内的端到端吞吐Req/s。因此HTTP benchmark 更适合回答实际部署时整体吞吐有没有回退这类问题而 fetch benchmark 更适合定位框架内部的微秒级开销变化。快速开始前置条件按 benchmarks/http-server/README.md 的说明运行该基准测试需要满足两个前提依赖要求说明Bunv1.0基准脚本本身用 Bun 运行且被测服务器也由 Bun 启动bun app.tsbombardier任意版本负载生成工具macOS 可用brew install bombardier安装其他平台见其官方安装说明从脚本实现看Bun 之所以是必选项是因为 benchmark.ts 使用node:child_process的spawn拉起子进程测试应用模板通过import { Hono } from ./src/index.ts直接引用 TypeScript 源码见 benchmark.ts这依赖 Bun 原生的 TS 执行能力。运行命令在仓库根目录执行cd benchmarks/http-server bun run benchmark.ts脚本运行后会在终端输出汇总表格同时将结果写入benchmarks/http-server/benchmark-results.md。整个流程大致是准备基线版本 → 准备目标版本 → 依次压测 → 计算变化率 → 输出 Markdown 表格。在 Pull Request 中的自动运行README 明确说明每个 Pull Request 都会自动运行 HTTP 基准测试并把结果以评论形式回复到 PR 上。这意味着该工具是 Hono 项目 CI 的一部分用于防止性能回归合入主干。对本仓库的贡献者而言本地先跑一遍基准测试是提交前验证性能无回退的推荐做法。命令行选项详解脚本在 benchmark.ts 的头部注释中列出了全部可用选项实现处见 benchmark.tsbun run benchmark.ts [options] 选项 --baselineref Git 引用作为性能基线默认: origin/main --targetref Git 引用作为被测目标默认: current即当前工作区 --runsnumber 每个基准的重复轮数默认: 1 --durationnumber 每轮压测时长单位秒默认: 10 --skip-tests 跳过端点正确性校验测试选项默认值作用--baselinereforigin/main基线版本的 Git 引用分支、tag 或 commit hash会被检出到临时环境与目标版本对比--targetrefcurrent被测版本默认值current直接使用当前工作区源码无需任何 Git 操作--runsnumber1重复压测轮数结果取多轮平均值轮数越多越稳定--durationnumber10每条 bombardier 压测命令的持续时间秒时间越长样本越充分--skip-tests关闭跳过压测前的端点校验适合只需粗略吞吐数据的场景两个被写死、不可通过命令行调整的关键常量也值得注意见 benchmark.ts并发数固定为500const concurrency 500三个压测场景ping / query / body分别对应三条固定的 bombardier 命令。实际使用示例# 默认对比 origin/main 与当前工作区每轮压测 10 秒 bun run benchmark.ts # 对比某个 tag 与当前工作区压测 3 轮、每轮 20 秒 bun run benchmark.ts --baselinev4.12.0 --runs3 --duration20 # 跳过端点校验快速跑一遍 bun run benchmark.ts --skip-tests被测应用三个典型场景无论 baseline 还是 target被测的都是同一个应用模板由getAppTemplate()生成见 benchmark.ts它覆盖了 Hono 最常见的三种路由形态import { Hono } from ./src/index.ts import { RegExpRouter } from ./src/router/reg-exp-router/index.ts const app new Hono({ router: new RegExpRouter() }) app .get(/, (c) c.text(Hi)) .post(/json, (c) c.req.json().then(c.json)) .get(/id/:id, (c) { const id c.req.param(id) const name c.req.query(name) c.header(x-powered-by, benchmark) return c.text(${id} ${name}) }) export default app对应脚本中的三个压测场景见 benchmark.ts场景路由压测命令要点考察点pingGET /bombardier --fasthttp -c 500 -d 10s http://127.0.0.1:3000/静态路由 纯文本响应的最短路径吞吐queryGET /id/1?namebunbombardier --fasthttp -c 500 -d 10s http://127.0.0.1:3000/id/1?namebun带路径参数:id与查询参数name的动态路由吞吐bodyPOST /jsonbombardier --fasthttp -c 500 -d 10s -m POST -H Content-Type:application/json -f body.json http://127.0.0.1:3000/json请求体解析c.req.json()与 JSON 响应c.json()吞吐值得注意的两个设计细节路由策略被固定为 RegExpRouter模板通过new Hono({ router: new RegExpRouter() })显式指定正则路由。Hono 的 RegExpRouter 基于 Trie 构建后合并为单个正则进行匹配实现见 src/router/reg-exp-router/router.ts 的通配正则缓存构建逻辑是 Hono 面向运行时吞吐优化的默认选择之一request body 文件setupTemp()会在临时目录生成body.json内容为{hello:world}见 benchmark.ts供 POST 场景通过-f参数作为请求体发送。执行流程从 Git 检出到结果汇总benchmark.ts 的main()函数串联了完整流水线下面按阶段拆解。阶段一准备 baseline 与 targetbuildVersion()见 benchmark.ts负责把两个版本各自的src目录与测试应用复制到隔离的临时目录target 为current时直接使用当前工作区不做任何 Git 操作baseline 为非current引用时依次执行git fetch origin拉取最新远程引用git stash push暂存当前未提交改动若存在并记录stash{0}以便恢复git checkout version检出目标版本bun install --frozen-lockfile安装该版本的锁定依赖拷贝src目录与生成的应用模板到临时目录最后git checkout -切回原分支并按需git stash pop恢复暂存内容。临时目录位于benchmarks/http-server/.benchmark-tempTEMP_DIR结束时会整体清理。阶段二端点正确性校验若未指定--skip-tests脚本会先以NODE_ENVproduction启动被测服务器见 benchmark.ts用fetch逐一对三个端点做断言GET /返回体必须为HiGET /id/1?namebun必须返回1 bun且响应头x-powered-by为benchmarkPOST /json返回体必须与请求体一致且content-type包含application/json。校验通过会打印✅ Tests passed for name任何断言失败都会抛出异常终止基准测试。这一步保证了压测的是功能正确的代码避免把明显损坏的版本纳入对比。阶段三bombardier 压测与结果解析runBenchmark()见 benchmark.ts为每个版本启动服务器后按 ping → query → body 顺序执行三条 bombardier 命令每条命令都使用--fasthttp启用 fasthttp 压测引擎与固定 500 并发。每轮结束后用正则/Reqs\/sec\s(\d[.|,]\d)/从输出中解析Reqs/sec数值解析失败记为 0最终得到三个场景各自的平均吞吐与总体平均值ping三个场景的平均Reqs/sec分别记为 ping、query、bodyoverall三者算术平均作为该版本的综合得分。多轮运行时--runs 1每轮都会重启服务器spawn(bun, [appPath], ...)NODE_ENVproduction再对每轮结果求平均以降低冷启动、GC 抖动等偶然因素影响。阶段四变化率计算与结果输出calculateChange()用((target - baseline) / baseline) * 100计算每个指标的百分比变化见 benchmark.ts正数表示 target 更快、负数表示回退。输出包含两部分终端打印Framework / Runtime / Average / Ping / Query / Body三行表格baseline、target、Change数字格式化为千分位变化率带/-前缀文件同一表格以## HTTP Performance Benchmark为标题写入benchmarks/http-server/benchmark-results.md供 CI 或 PR 评论引用。结果解读示例一次典型运行结束后终端会输出类似如下的结构数值为格式示意具体结果取决于机器与版本| Framework | Runtime | Average | Ping | Query | Body | | --- | --- | --- | --- | --- | --- | | hono (origin/main) | bun | 123,456.78 | 130,000.00 | 120,000.00 | 120,370.34 | | hono (current) | bun | 125,000.00 | 132,000.00 | 121,500.00 | 121,500.00 | | Change | | 1.25% | 1.54% | 1.25% | 0.94% |判断口径Change行为正说明当前分支相对基线更快为负则说明存在回退风险需要结合具体改动定位原因。注意本工具对比的是同一个框架的两个 Git 版本并不产出与第三方框架的横向排名因此不宜将这里的数字与其他仓库的 benchmark 直接比较。延伸到其他基准测试fetch 与 routersHTTP benchmark 不是仓库中唯一的性能工具理解它在你需要更细粒度定位时可与其他两套配套使用benchmarks/fetch进程内测量app.fetch()开销。./compare.sh会在每轮用独立进程分别测工作区与某个 Git 引用默认main并每轮反转两者顺序避免同进程内 JIT/GC 预热与执行顺序造成偏差支持RUNTIMEnode、ROUNDS5等环境变量最终用 benchmarks/fetch/summarize.mts 汇总每轮平均值的中位数与全部原始轮次值。当 HTTP 层出现回退而想确认是不是路由/响应构造本身的瓶颈时可以用它快速定位benchmarks/routers面向路由器本身的横向对比覆盖 find-my-way、express、koa-router、Hono RegExpRouter、Hono TrieRouter 等常用路由实现bun run bench:bun与bun run bench:node分别测 Bun 与 Node 环境。若怀疑吞吐差异源于路由选择可参考其结果。注意事项与适用前提被测运行时是 Bun应用由bun启动见 benchmark.ts因此结果反映的是 Bun 运行时下的 Hono 表现不代表 Node.js、Deno、Cloudflare Workers 等环境固定并发 500并发数不可调对高延迟场景或资源受限机器可能造成过度饱和解读数字时需结合本机硬件需要 Git 引用可访问默认 baseline 为origin/main首次运行会执行git fetch origin离线环境下需改用本地分支/tag如--baselinev4.12.0会临时改动工作区baseline 构建过程中涉及git stash/git checkout虽然结束后会恢复仍建议在干净的提交状态下运行避免意外临时目录.benchmark-temp在结束时自动删除。小结Hono HTTP Benchmark 是一个轻量而完整的性能回归守护工具一条bun run benchmark.ts命令即可完成检出基线 → 校验端点 → bombardier 压测 → 计算变化率 → 输出 Markdown 报告的全流程其 PR 自动评论机制让性能变化在合入前即可见。结合 benchmarks/fetch 的进程内开销测量与 benchmarks/routers 的路由器横向对比你可以从整体吞吐 → 框架开销 → 路由层三个粒度全面评估 Hono 的性能特征。【免费下载链接】honoWeb framework built on Web Standards项目地址: https://gitcode.com/GitHub_Trending/ho/hono创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考