wrk是压测Iris接口的唯一靠谱起点，因其多线程+事件驱动架构能真实反映高并发下延迟稳定性；必须调高ulimit -n和somaxconn等系统限制，否则连接数超限会导致QPS上不去、connection refused或timeout。
压测 Iris 接口，别用 curl 或浏览器点——wrk 是唯一靠谱的起点，且必须调高系统限制，否则 90% 的“性能差”其实是环境卡死。
为什么 wrk -c 1024 一跑就卡住
Linux 默认 ulimit -n 是 1024，wrk -c 1024 意味着客户端要建满 1024 个连接，服务端 accept 队列、文件描述符、TIME_WAIT 端口全会撞墙。现象是 QPS 上不去、大量 connection refused 或 timeout。
- 服务端启动前务必执行：
ulimit -n 65535，并确认sysctl net.core.somaxconn≥ 65535 - 客户端（wrk 所在机器）同样要调高
ulimit -n，否则连不出去 - 本地单机压测时，客户端和服务端共用一个网卡和端口范围，
wrk -c 1024 -t 8很快耗尽本地可用端口（尤其是短连接），必须拆到两台机器 - 检查是否误启了
GODEBUG=gctrace=1，GC 日志 IO 会严重拖慢吞吐，生产压测必须关掉
怎么写一个能真实反映 Iris 性能的压测命令
Iris 的优势在高并发下延迟稳定，所以压测参数得匹配这个特点：连接数够、时间够长、线程分布合理。用 ab 或 hey 容易因单线程瓶颈或连接复用策略失真。
- 推荐命令：
wrk -d 100s -c 1024 -t 8 http://localhost:8080/ping -
-t 8对应 GOMAXPROCS=8，避免 goroutine 调度争抢；若 CPU 核数少，按核数设（如 4 核就用-t 4） -
-d 100s是关键：短于 30 秒的压测看不到 GC 周期影响和延迟抖动，Iris 的 ±3.80ms 这个指标只有在稳态下才准 - 接口路径选轻量 endpoint，比如内置
/ping或自定义返回"ok"的 handler，排除业务逻辑干扰
压测时 Iris 应用本身要注意什么
框架快不等于你写的代码快。中间件、日志、body 解析这些环节，稍不注意就把 QPS 拉低一半。
- 关掉所有非必要中间件：尤其
LogRequestBody: true和LogResponseBody: true，它们强制读取整个 body，大请求下内存暴涨 + GC 频繁 - 静态文件别走
iris.FileServer，它不走内核零拷贝；压测含图片/JS/CSS 时，要么用 Nginx 托管，要么改用http.FileServer+http.StripPrefix绕过 Iris 中间件链 - 确保没在中间件里调
ctx.ReadBody()或ctx.PostValues()——body 被消费一次后，后续 handler 再调ctx.ReadJSON()就会失败或空数据 - 如果用了 Redis 限流等中间件，压测前确认 Redis 连接池已预热（如
redis.NewClient().Ping()），否则首波请求会卡在连接建立
看到 QPS 只有 2–3 万，先查这三件事
实测 Iris 在标准配置下稳定 7.5 万 QPS，低于 5 万基本可断定是环境或配置问题，不是框架瓶颈。
- 执行
lsof -i :8080 | wc -l，看服务端 ESTABLISHED 连接数是否远低于-c设置值（说明连接根本建不起来） - 用
go tool pprof http://localhost:8080/debug/pprof/goroutine?debug=1查是否有 goroutine 卡在read或write，常见于未设超时的 gRPC 调用或 Redis 阻塞命令 - 检查 Iris 启动日志是否输出
Now listening on...后立刻有 panic 或 warning，某些中间件初始化失败会导致静默降级为单协程处理
真正难的不是跑出数字，而是让 wrk 的每条连接都打到 Iris 的事件循环里，而不是被系统层拦在半路。很多“性能问题”本质是没把 Linux 网络栈和 Go runtime 的协作边界理清楚。
