简介本资源为wrk-4.1.0的Linux版本安装包面向需要进行Web服务器性能压测的开发者与运维人员。wrk是一款用C语言编写的高性能HTTP基准测试工具擅长高并发、短连接场景下的压力测试相比JMeter、ab等工具更轻量、更易扩展。压缩包为7z格式整体约168.72MB包内文件以源码及编译相关文件为主需解压后编译生成可执行文件并可通过Lua脚本定制请求头、请求体与请求间隔等复杂测试场景。资源配套内容涵盖安装编译、权限设置、基本命令与选项说明、Lua脚本用法及结果指标解析并对比了wrk与JMeter、ab的适用差异可帮助读者快速搭建压测环境、理解吞吐量与响应时间等关键指标定位服务器性能瓶颈。目前已有586人学习下载适合具备一定Linux基础、希望深入掌握HTTP性能测试的中高级用户参考。1. 压测工具选型为什么我最终把 wrk-4.1.0-linux 留在了服务器上很多团队做性能测试的路径都差不多先用 ab 跑个几百并发发现压不上去换 JMeter 画几张聚合报告再往后遇到长连接和 HTTPS 场景又开始卡壳。我最早也是这么一路试过来的直到某次排查一个接口在 8000 并发下的尾延迟问题才真正把 wrk-4.1.0-linux 当成主力工具用起来。它解决的核心问题很直接在单机上用极少的资源把 HTTP 服务的吞吐和延迟压到一个足够真实的量级同时给出可读的延迟分布而不是只丢一个平均值给你。wrk 属于事件驱动型压测工具底层用 epoll 做多路复用配合多线程和可选的 Lua 脚本扩展单进程就能把一台普通 4 核机器的网络栈吃满。它适合谁适合已经过了「接口能不能通」阶段、开始关心「QPS 天花板在哪、P99 抖不抖、长连接下会不会雪崩」的后端和运维同学。如果你还在用单线程工具跑 100 并发就以为测到了极限那 wrk 大概率会刷新你的认知。这一篇就按「装起来 → 跑通 → 调参 → 避坑 → 进阶」的顺序把 wrk-4.1.0-linux 这套东西讲透。2. 把 wrk-4.1.0-linux 跑起来编译、依赖与最小验证2.1 为什么这个版本在 Linux 上要自己编译wrk 官方并不总是提供现成的 Linux 二进制包4.1.0 这个版本在很多发行版仓库里也没有直接收录所以常见做法是拉源码自己编译。它的依赖非常干净一个 C 编译器、make、以及 OpenSSL 开发库如果要压 HTTPS。相比那些需要 JVM、需要装一堆插件的工具wrk 的编译过程基本不会翻车前提是你把开发库装全。先确认系统里有没有编译环境。下面这几条命令在主流发行版上都能用按你的包管理器选一条执行即可。# Debian/Ubuntu 系装编译器和 OpenSSL 开发库 sudo apt-get update sudo apt-get install -y build-essential libssl-dev git # RHEL/CentOS 系装对应的开发包 sudo yum groupinstall -y Development Tools sudo yum install -y openssl-devel git这里build-essential提供 gcc 和 makelibssl-dev是 HTTPS 压测的前提。如果你只压 HTTP理论上可以不带 OpenSSL但实际项目里 HTTPS 几乎躲不掉建议一次装齐省得后面重新编译。2.2 编译安装与版本确认拿到源码后进入目录直接 make 即可。wrk 的 Makefile 写得比较克制默认会链接系统 OpenSSL。# 进入源码目录后编译-j 后面跟 CPU 核数加速编译 make -j4 # 编译产物是当前目录下的 wrk 可执行文件 # 把它放到 PATH 里方便全局调用 sudo cp wrk /usr/local/bin/ # 确认版本输出应包含 4.1.0 wrk --versionmake -j4里的 4 表示并行编译任务数按你机器的核数调整核多就写大一点。编译完成后不要急着跑压测先执行wrk --version确认版本号避免装了个旧版本还以为参数不生效。如果编译报 OpenSSL 相关的链接错误八成是开发库没装或路径不对回头检查libssl-dev/openssl-devel是否真的装上了。2.3 最小可用压测命令与输出解读先用一条最简单的命令验证工具链是否正常。找一个你确定能访问的测试接口别一上来就打生产。# -t 线程数 -c 连接数 -d 持续时间 最后跟目标 URL wrk -t4 -c200 -d30s http://127.0.0.1:8080/health跑完之后输出大致长这样重点看四块Requests/sec是吞吐Latency是平均延迟Stdev是延迟标准差下面那几行50% / 75% / 90% / 99%才是真正决定体验的延迟分布。很多人只盯 Requests/sec结果线上 P99 已经飙到几百毫秒还没察觉这就是只看平均值的代价。-t4表示开 4 个线程-c200表示维持 200 个连接-d30s表示压 30 秒。线程数一般不要超过 CPU 核数连接数则根据你要模拟的并发规模来定这两个参数后面还会细说。3. 参数怎么调线程、连接、超时与脚本扩展3.1 线程数与连接数的配比关系wrk 的并发模型是「多线程 每线程一个事件循环」每个线程内部用 epoll 管理自己那部分连接。所以-t决定的是并行的事件循环数量-c决定的是总连接数平均下来每个线程扛c/t个连接。这个比值直接决定了单线程的事件循环压力。我的经验配比是这样的4 核机器上-t4起步-c从 100 开始每次翻倍往上试观察Requests/sec什么时候不再增长甚至回落。如果-c加到 2000 但吞吐反而掉了说明瓶颈已经不在服务端而在压测机自己的网络栈或文件描述符上限。这时候要做两件事一是确认压测机的ulimit -n够大二是别再无脑加连接数。# 查看当前进程可打开的文件描述符上限 ulimit -n # 临时调高到 65535只对当前 shell 生效 ulimit -n 65535文件描述符上限是压测里最容易被忽略的坑。每个连接占一个 fd-c开到几千而ulimit -n还是默认的 1024wrk 会直接报错或者连接建立失败表现就是吞吐低得离谱你还以为是服务端不行。3.2 超时设置与延迟统计口径wrk 默认的超时是 2 秒这个值在高并发下经常不够用尤其是被测服务有慢查询的时候。超时的连接会被计入错误但 wrk 的错误统计不像某些工具那么显眼容易漏看。# --timeout 设置单次请求超时单位可以是 s/ms wrk -t4 -c500 -d60s --timeout 5s http://127.0.0.1:8080/api/list # --latency 会打印更完整的延迟分布排查尾延迟必加 wrk -t4 -c500 -d60s --latency http://127.0.0.1:8080/api/list--timeout 5s把超时放宽到 5 秒适合被测接口本身响应偏慢的场景。--latency这个参数强烈建议每次都带上它会额外输出最大值和更细的分位数排查 P99 抖动时没有它基本等于盲人摸象。注意延迟统计是客户端视角的包含了网络往返所以压测机和被测服务如果在不同机房这个数字会明显偏大别拿它当服务端处理时间的绝对值。3.3 用 Lua 脚本模拟真实请求wrk 真正拉开差距的地方是 Lua 脚本扩展。默认它只会对同一个 URL 发 GET但真实业务里往往要带 header、要 POST body、要参数化。wrk 内置了 LuaJIT脚本写起来很轻。-- post.lua模拟带 JSON body 的 POST 请求 -- wrk.method / wrk.body / wrk.headers 是内置可写字段 wrk.method POST wrk.body {userId:123,page:1} wrk.headers[Content-Type] application/json wrk.headers[Authorization] Bearer test-token -- 每个请求发出前调用可在这里做参数随机化 request function() -- 用随机数避免服务端缓存命中测出真实压力 local uid math.random(1, 100000) local body {userId: .. uid .. ,page:1} return wrk.format(POST, /api/query, nil, body) endwrk.method、wrk.body、wrk.headers是全局默认值request函数则是每个请求的钩子返回什么就发什么。上面用math.random随机化 userId是为了绕开服务端可能存在的缓存否则你压的其实是缓存而不是真实逻辑。wrk.format的四个参数依次是方法、路径、headers、bodyheaders 传 nil 表示沿用全局设置。脚本用-s加载wrk -t4 -c300 -d60s --latency -s post.lua http://127.0.0.1:8080/api/query注意 URL 里的路径会被脚本里的路径覆盖所以脚本里写清楚目标路径就行命令行 URL 主要提供 host 和端口。4. 避坑与排查那些让压测结果失真的细节4.1 压测机自己先成了瓶颈现象-c加到 1000 以上吞吐不升反降CPU 里sys占比很高。原因通常是压测机的网络中断处理、fd 上限或者 wrk 线程数配置不合理压测机先扛不住了。解决先看top里 wrk 进程的 CPU 分布如果sys远高于usr说明大量时间花在系统调用上把-t调到等于或略小于核数同时确认ulimit -n足够大必要时换一台配置更高的机器专门做压测端。4.2 只压 localhost 导致结果虚高现象本地压 localhost 跑出几十万 QPS换到真实网络环境直接掉一个数量级。原因是 loopback 不走物理网卡省掉了协议栈和网卡的中断开销数字好看但不真实。解决压测机和被测服务尽量放在同一内网但不同机器上至少跨一次真实网卡。如果只能本机压心里要清楚这个数字是上限参考不能直接当容量结论。4.3 连接复用掩盖了握手开销现象压测结果很漂亮但线上用户首次访问很慢。原因是 wrk 默认复用连接测的是长连接下的稳态吞吐而真实用户每次都要经历 TCP 握手甚至 TLS 握手。解决如果业务是短连接场景需要在脚本里主动关闭连接或者用Connection: close头模拟HTTPS 场景要意识到 wrk 的 TLS 会话复用同样会美化结果评估时要留出握手余量。4.4 忽略错误计数现象吞吐数字正常但服务端日志里一堆 5xx。原因是 wrk 默认输出里错误信息不显眼很多人只看 Requests/sec 就下结论。解决压测结束后一定要看输出里的Socket errors和Non-2xx responses两行非 2xx 的响应会被单独计数如果这个数字不为零说明你的吞吐是建立在失败请求上的毫无意义。4.5 持续时间太短导致数据不稳现象两次同样的命令结果差 20% 以上。原因是-d太短压测还没进入稳态就结束了启动阶段的抖动被放大。解决正式压测-d至少 60 秒最好 120 秒以上并且跑三轮取中间值。前 10 秒的数据基本可以当预热丢掉wrk 本身不提供分段统计但你可以通过延长总时长来稀释启动阶段的影响。5. 进阶技巧把 wrk 用成可复现的压测基线5.1 用固定脚本固化压测场景压测最大的敌人是「每次跑的条件都不一样」。我的习惯是把线程、连接、时长、脚本、目标 URL 全部写进一个 shell 脚本每次压测只改版本号或环境变量保证可比性。#!/bin/bash # bench.sh固定参数的压测基线脚本 TARGET${1:-http://127.0.0.1:8080/api/query} THREADS4 CONNS500 DURATION120s echo target: $TARGET echo threads$THREADS conns$CONNS duration$DURATION # 跑三轮人工对比稳定性 for i in 1 2 3; do echo round $i wrk -t$THREADS -c$CONNS -d$DURATION --latency --timeout 5s \ -s post.lua $TARGET sleep 10 # 轮次之间留冷却避免服务端积压影响下一轮 done这个脚本的价值在于「可复现」。TARGET用参数传入方便切换环境三轮之间sleep 10是给服务端冷却避免上一轮积压的请求影响下一轮。跑完把三轮的Requests/sec和99%延迟拉出来对比如果波动超过 10%说明要么环境不稳要么压测参数还没到稳态结论不能采信。5.2 延迟分布比吞吐更值得盯很多人做容量规划只问「能扛多少 QPS」但真正影响用户体验的是尾延迟。wrk 的--latency输出里99%那一行才是关键。我的判断标准是如果 P99 超过平均延迟的 5 倍说明系统里存在长尾可能是 GC、锁竞争或者慢查询这时候即使吞吐达标也不能上线。把 P50、P90、P99 三个值记下来作为每次发版的对比基线比单看一个 QPS 有用得多。5.3 结合服务端指标交叉验证wrk 给的是客户端视角服务端的 CPU、内存、连接数、GC 日志要同步看。常见做法是压测时另开一个终端跑top、ss -s或者看应用的监控面板。如果客户端显示吞吐到顶了但服务端 CPU 才 40%那瓶颈大概率在压测机或者网络反过来服务端 CPU 打满而吞吐上不去才是真正的服务端瓶颈。两边对不上先怀疑压测端这是我踩过好几次坑之后养成的习惯。5.4 一个容易忽略的收尾动作压测跑完别急着关终端先把输出重定向存下来。我一般会在脚本里加| tee result_$(date %s).log把每轮结果落盘。原因很简单压测当时觉得数字都记住了过两天要对比新版本时翻聊天记录找不全。存成文件配合版本号命名才是能长期用的基线。这个习惯看起来琐碎但真到要证明「这次优化到底有没有效果」的时候它就是你的后悔药。希望帮到你。本文还有配套的精品资源点击获取