revel框架压测需禁用dev模式、配对连接池并调优go运行时；真实承载力取决于生产配置与系统参数，而非框架自身性能。
Revel 框架本身不自带压测能力，必须靠外部工具驱动；它的实际承载力不取决于框架“能跑多快”，而取决于你是否关掉了开发模式、是否配对了连接池、以及 Go runtime 的 GOMAXPROCS 和 GODEBUG 是否被误调。
Revel 启动时务必禁用 dev 模式
Revel 默认在 conf/app.conf 里启用 mode=dev，这会触发模板热重载、文件监听、详细错误页、请求日志全量打印等行为——这些在压测中全是性能杀手。
- 生产部署前必须改为
mode=prod，否则 wrk 压出的 QPS 可能只有真实值的 1/5 -
run.mode=dev和app.mode=dev是两个独立开关，都要检查 - 改完后记得清空
tmp/目录，否则旧的热编译缓存仍可能生效
wrk 测试 Revel 时的关键参数组合
用 wrk 测 Revel，不能只看平均 QPS；它对连接复用和延迟抖动特别敏感。默认参数下容易低估其真实能力。
- 必须加
-H "Connection: keep-alive"，否则 Revel 的 HTTP handler 会为每个请求重建 TLS/HTTP 状态 - 推荐起始命令：
wrk -t4 -c400 -d30s --latency -H "Connection: keep-alive" http://localhost:9000/health - 若压测中出现大量
non-2xx or 3xx responses，先检查 Revel 日志里是否有http: Accept error—— 这通常是系统ulimit -n不足，而非 Revel 本身扛不住
Revel 的瓶颈通常不在框架层
Revel 基于 Go net/http，路由和中间件开销极低；真正卡住吞吐的，往往是下游依赖或 Go 运行时配置。
- 数据库场景下，
sql.DB.SetMaxOpenConns(20)是常见误配——Revel 并发高时连接池立刻耗尽，P99 延迟飙升，但 QPS 看似还行 - 如果用了
gorilla/sessions或自定义 session 中间件，确保没在 handler 里做同步磁盘写（比如文件存储 session） - Go 1.21+ 默认启用异步抢占，但若压测机 CPU 被占满，可临时加环境变量：
GODEBUG=asyncpreemptoff=1观察是否缓解调度抖动
Revel 的“极限”不是个固定数字，它随你关闭了多少调试钩子、下游服务响应多稳、以及 Linux 的 net.core.somaxconn 和 fs.file-max 设得多高而浮动——别信单次 wrk 输出的峰值，要盯住 P99 延迟是否稳定、错误率是否突增、内存 RSS 是否线性上涨。
