别等线上崩了才想起压测用 oha 实战摸清 HTTP 服务性能底牌【免费下载链接】ohaOhayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.项目地址: https://gitcode.com/gh_mirrors/oh/oha很多压测工具只会丢给你一堆数字而 oha 用 Rust 写成一条命令就能发起 HTTP 负载并用实时 TUI 动画把成功率与延迟分布直接演给你看。这篇实战指南面向刚接触压测的开发者与运维带你从零跑通一次接口性能体检。图执行oha -z 6s http://localhost:3000时终端会切进实时刷新的压测监控界面一个周五晚上的救场周五 23 点上线前最后一轮联调。测试同学在群里丢来一句/api/order这个接口有时候要 2 秒才返回。代码没改、日志没报错、数据库负载正常重启也没用。几个人围着服务器干瞪眼谁都不敢拍胸脯说这只是偶发。这种时候你真正需要的不是更多日志而是当场给接口把把脉——持续打流量看它到底怎么响应。这就要说到 HTTP 压测了。压测不是玄学先搞懂它在做什么一句话解释压测模拟一群真实用户同时向你的服务器发请求看它撑不撑得住、哪里先掉链子。它的原理像给服务器戴上一副听诊器你不断制造请求让服务持续跳动然后竖起耳朵听响应时间、成功率这些心跳声有没有异常。听诊器好不好用直接决定你能不能第一时间锁定病灶。传统压测工具的问题在于要么配置文件半天写不对要么跑完丢来一堆冷冰冰的数字过程中发生了什么全靠脑补。而 oha 的思路很直接——压测的过程本身就要看得见。小背景oha 的灵感来自知名工具 rakyll/hey但它用 Rust 重写底层跑在 tokio 异步运行时上实时界面由 ratatui 渲染产物是一个很轻的二进制文件。完整的参数说明在项目内的 README.md 里随时可查。三行命令装好零配置开跑安装 oha 比想象中省事按你的系统挑一条场景命令macOSHomebrewbrew install ohaArch Linuxpacman -S ohaWindowswingetwinget install hatoo.oha有 Rust 环境cargo install oha容器环境docker run --rm -it --networkhost hatoo/oha:latest URL想从源码自己编译也完全可行git clone https://gitcode.com/gh_mirrors/oh/oha cd oha cargo build --release编译产物在target/release/oha放进 PATH 就能全局使用。装完先确认一下版本oha --version能打印出版本号说明工具已经就位。整个过程用不了几分钟接下来进入正题。第一次压测看着数据在屏幕上呼吸假设你本地有个服务跑在 3000 端口想看看它承受压力的能力一行命令就够oha -z 6s http://localhost:3000-z 6s表示持续压 6 秒后面跟目标地址。命令一执行终端立刻切进实时刷新的界面——这正是 oha 最抓眼的地方右上角是正在处理的请求量像发动机转速表一样不停跳动不同阶段耗时DNS 解析、TCP 连接、TLS 握手分色展示绿、黄、红三档对应延迟从低到高成功率数字随请求结果实时变色一片绿说明稳泛红就得提高警惕。你可以把压测想象成让服务器上跑步机而这个界面就是贴在墙上的仪表盘每跑一步数据都清清楚楚。这套实时渲染逻辑在 src/monitor.rs 里实现感兴趣可以翻源码看看。如果只想要纯结果、不想要动画加个--no-tui就行顺带还能跑得更快——省去了实时收集数据的开销。读懂体检报告先抓这 4 个数字压测结束oha 会在终端输出一份完整报告对应源码 src/printer.rs。新手别贪多先盯住 4 个数字Success rate请求成功率。低于 99% 说明接口确实有问题先看错误码集中在 4xx 还是 5xxRequests/sec每秒处理的请求数也就是吞吐量衡量服务消化能力的核心指标Latency distribution延迟百分位。P50 是大多数用户感受到的速度P99 是体验最差那 1% 用户的感受——偶发超时往往就藏在这里Slowest / Fastest / Average最慢、最快、平均响应时间帮你快速判断延迟分布是否健康。理解百分位的一个土办法100 个人排队打饭P50 是排在正中间那个人等了多久P99 是倒数第二那个人等了多久。优化体验重点就是别让最后那几个人等太久。除了默认的文本报告还可以输出 JSON字段结构见 schema.json方便程序解析和 CSV每个请求一行明细oha -z 6s --output-format json http://localhost:3000oha -z 6s --output-format csv http://localhost:3000别让压测数据骗了你三个常见大坑跑出报告不等于结论可靠。第一次用 oha结果往往好得不真实问题多半出在下面三点坑一默认开启 keep-alive请求都复用同一条连接。真实用户可不会这么念旧每次新建连接才是常态。关掉它数字立刻接地气oha -z 6s --disable-keepalive http://localhost:3000坑二压测机太闲漏掉了排队中的请求。当服务器忙不过来时请求会在队列里干等传统工具常常跳过这些请求不统计延迟被严重低估——这就是著名的协调遗漏Coordinated Omission问题。oha 给了专门开关oha -z 6s -q 200 --latency-correction http://localhost:3000-q 200把整体速率限制在每秒 200 个请求--latency-correction则把排队等待时间也计入延迟还你一个真实的 P99。坑三用默认参数跑代表不了真实流量。oha 默认 200 个请求、50 条并发连接只适合随便看看。正经压测要自己指定并发量oha -z 30s -c 200 http://localhost:3000-c 200表示同时保持 200 条连接发请求。把这三个参数组合起来才是一份有参考价值的体检。进阶玩法突发流量、随机 URL、带请求体的压测真实世界的流量从来不是均匀的oha 的几个参数能帮你模拟更刁钻的场景。模拟突发流量比如秒杀瞬间的请求洪峰oha -n 10 --burst-delay 2s --burst-rate 4 http://localhost:3000意思是每 2 秒集中发 4 个请求共发 10 个。突发场景下缓存和连接池的真实表现一试便知。随机 URL 压测防止缓存把所有请求都喂饱oha --rand-regex-url http://127.0.0.1/[a-z][a-z][0-9]URL 会按正则规则不断变化每次都打到不同路径适合验证冷请求下的真实性能。从文件读取 URL 列表直接复现线上访问日志的流量分布oha --urls-from-file urls.txturls.txt每行一个 URLoha 会随机挑选访问。用真实日志生成这个文件压测几乎等于回放线上流量。带请求体的 POST 压测同样常用oha -m POST -d {name:oha} -T application/json http://localhost:3000/api/order-m指定请求方法-d指定请求体-T指定 Content-Type。需要带鉴权信息就追加-Hoha -z 6s -H Authorization: Bearer xxx https://api.example.com把压测写进日常工作流压测不该是上线前才临时抱佛脚的大扫除它完全可以变成日常习惯。oha 在这件事上给了两个很实用的出口结果落库历史对比。把每次压测结果写进 SQLite想看某次改动对性能的影响直接翻历史记录oha -z 6s --db-url test.db http://localhost:3000JSON 输出接进 CI。在持续集成流水线里跑一次压测用 JSON 结果做断言比如P99 必须小于 200ms不达标就拦下这次发布。一次配置以后每次提交自动体检。现在就动手跑一次 30 秒的体检回到开头那个周五晚上其实你只需要装好 oha对那个偶尔 2 秒的接口执行一次压测成功率、延迟分布、错误码全在屏幕上实时跳动病灶往往一眼就能圈出来。压测不是玄学工具也不该是负担。现在打开终端对你最关心的那个接口跑一次oha -z 6s http://localhost:3000把第一次跑出来的 Success rate 和 P99 记下来这就是你服务的体检基线。下次代码改完再跑一次做对比——性能是变好还是变坏数据会直接告诉你答案。【免费下载链接】ohaOhayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.项目地址: https://gitcode.com/gh_mirrors/oh/oha创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 别等线上崩了才想起压测，用 oha 实战摸清 HTTP 服务性能底牌
别等线上崩了才想起压测用 oha 实战摸清 HTTP 服务性能底牌【免费下载链接】ohaOhayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.项目地址: https://gitcode.com/gh_mirrors/oh/oha很多压测工具只会丢给你一堆数字而 oha 用 Rust 写成一条命令就能发起 HTTP 负载并用实时 TUI 动画把成功率与延迟分布直接演给你看。这篇实战指南面向刚接触压测的开发者与运维带你从零跑通一次接口性能体检。图执行oha -z 6s http://localhost:3000时终端会切进实时刷新的压测监控界面一个周五晚上的救场周五 23 点上线前最后一轮联调。测试同学在群里丢来一句/api/order这个接口有时候要 2 秒才返回。代码没改、日志没报错、数据库负载正常重启也没用。几个人围着服务器干瞪眼谁都不敢拍胸脯说这只是偶发。这种时候你真正需要的不是更多日志而是当场给接口把把脉——持续打流量看它到底怎么响应。这就要说到 HTTP 压测了。压测不是玄学先搞懂它在做什么一句话解释压测模拟一群真实用户同时向你的服务器发请求看它撑不撑得住、哪里先掉链子。它的原理像给服务器戴上一副听诊器你不断制造请求让服务持续跳动然后竖起耳朵听响应时间、成功率这些心跳声有没有异常。听诊器好不好用直接决定你能不能第一时间锁定病灶。传统压测工具的问题在于要么配置文件半天写不对要么跑完丢来一堆冷冰冰的数字过程中发生了什么全靠脑补。而 oha 的思路很直接——压测的过程本身就要看得见。小背景oha 的灵感来自知名工具 rakyll/hey但它用 Rust 重写底层跑在 tokio 异步运行时上实时界面由 ratatui 渲染产物是一个很轻的二进制文件。完整的参数说明在项目内的 README.md 里随时可查。三行命令装好零配置开跑安装 oha 比想象中省事按你的系统挑一条场景命令macOSHomebrewbrew install ohaArch Linuxpacman -S ohaWindowswingetwinget install hatoo.oha有 Rust 环境cargo install oha容器环境docker run --rm -it --networkhost hatoo/oha:latest URL想从源码自己编译也完全可行git clone https://gitcode.com/gh_mirrors/oh/oha cd oha cargo build --release编译产物在target/release/oha放进 PATH 就能全局使用。装完先确认一下版本oha --version能打印出版本号说明工具已经就位。整个过程用不了几分钟接下来进入正题。第一次压测看着数据在屏幕上呼吸假设你本地有个服务跑在 3000 端口想看看它承受压力的能力一行命令就够oha -z 6s http://localhost:3000-z 6s表示持续压 6 秒后面跟目标地址。命令一执行终端立刻切进实时刷新的界面——这正是 oha 最抓眼的地方右上角是正在处理的请求量像发动机转速表一样不停跳动不同阶段耗时DNS 解析、TCP 连接、TLS 握手分色展示绿、黄、红三档对应延迟从低到高成功率数字随请求结果实时变色一片绿说明稳泛红就得提高警惕。你可以把压测想象成让服务器上跑步机而这个界面就是贴在墙上的仪表盘每跑一步数据都清清楚楚。这套实时渲染逻辑在 src/monitor.rs 里实现感兴趣可以翻源码看看。如果只想要纯结果、不想要动画加个--no-tui就行顺带还能跑得更快——省去了实时收集数据的开销。读懂体检报告先抓这 4 个数字压测结束oha 会在终端输出一份完整报告对应源码 src/printer.rs。新手别贪多先盯住 4 个数字Success rate请求成功率。低于 99% 说明接口确实有问题先看错误码集中在 4xx 还是 5xxRequests/sec每秒处理的请求数也就是吞吐量衡量服务消化能力的核心指标Latency distribution延迟百分位。P50 是大多数用户感受到的速度P99 是体验最差那 1% 用户的感受——偶发超时往往就藏在这里Slowest / Fastest / Average最慢、最快、平均响应时间帮你快速判断延迟分布是否健康。理解百分位的一个土办法100 个人排队打饭P50 是排在正中间那个人等了多久P99 是倒数第二那个人等了多久。优化体验重点就是别让最后那几个人等太久。除了默认的文本报告还可以输出 JSON字段结构见 schema.json方便程序解析和 CSV每个请求一行明细oha -z 6s --output-format json http://localhost:3000oha -z 6s --output-format csv http://localhost:3000别让压测数据骗了你三个常见大坑跑出报告不等于结论可靠。第一次用 oha结果往往好得不真实问题多半出在下面三点坑一默认开启 keep-alive请求都复用同一条连接。真实用户可不会这么念旧每次新建连接才是常态。关掉它数字立刻接地气oha -z 6s --disable-keepalive http://localhost:3000坑二压测机太闲漏掉了排队中的请求。当服务器忙不过来时请求会在队列里干等传统工具常常跳过这些请求不统计延迟被严重低估——这就是著名的协调遗漏Coordinated Omission问题。oha 给了专门开关oha -z 6s -q 200 --latency-correction http://localhost:3000-q 200把整体速率限制在每秒 200 个请求--latency-correction则把排队等待时间也计入延迟还你一个真实的 P99。坑三用默认参数跑代表不了真实流量。oha 默认 200 个请求、50 条并发连接只适合随便看看。正经压测要自己指定并发量oha -z 30s -c 200 http://localhost:3000-c 200表示同时保持 200 条连接发请求。把这三个参数组合起来才是一份有参考价值的体检。进阶玩法突发流量、随机 URL、带请求体的压测真实世界的流量从来不是均匀的oha 的几个参数能帮你模拟更刁钻的场景。模拟突发流量比如秒杀瞬间的请求洪峰oha -n 10 --burst-delay 2s --burst-rate 4 http://localhost:3000意思是每 2 秒集中发 4 个请求共发 10 个。突发场景下缓存和连接池的真实表现一试便知。随机 URL 压测防止缓存把所有请求都喂饱oha --rand-regex-url http://127.0.0.1/[a-z][a-z][0-9]URL 会按正则规则不断变化每次都打到不同路径适合验证冷请求下的真实性能。从文件读取 URL 列表直接复现线上访问日志的流量分布oha --urls-from-file urls.txturls.txt每行一个 URLoha 会随机挑选访问。用真实日志生成这个文件压测几乎等于回放线上流量。带请求体的 POST 压测同样常用oha -m POST -d {name:oha} -T application/json http://localhost:3000/api/order-m指定请求方法-d指定请求体-T指定 Content-Type。需要带鉴权信息就追加-Hoha -z 6s -H Authorization: Bearer xxx https://api.example.com把压测写进日常工作流压测不该是上线前才临时抱佛脚的大扫除它完全可以变成日常习惯。oha 在这件事上给了两个很实用的出口结果落库历史对比。把每次压测结果写进 SQLite想看某次改动对性能的影响直接翻历史记录oha -z 6s --db-url test.db http://localhost:3000JSON 输出接进 CI。在持续集成流水线里跑一次压测用 JSON 结果做断言比如P99 必须小于 200ms不达标就拦下这次发布。一次配置以后每次提交自动体检。现在就动手跑一次 30 秒的体检回到开头那个周五晚上其实你只需要装好 oha对那个偶尔 2 秒的接口执行一次压测成功率、延迟分布、错误码全在屏幕上实时跳动病灶往往一眼就能圈出来。压测不是玄学工具也不该是负担。现在打开终端对你最关心的那个接口跑一次oha -z 6s http://localhost:3000把第一次跑出来的 Success rate 和 P99 记下来这就是你服务的体检基线。下次代码改完再跑一次做对比——性能是变好还是变坏数据会直接告诉你答案。【免费下载链接】ohaOhayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.项目地址: https://gitcode.com/gh_mirrors/oh/oha创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考