1. 项目概述wrk是什么wrk是一款现代化的HTTP基准测试工具采用多线程设计能够高效地模拟高并发HTTP请求。与传统的abApacheBench或JMeter相比wrk在单机性能测试场景下展现出显著优势——在我的压力测试实践中一台普通开发机8核CPU使用wrk可以轻松产生5万 QPS的负载而内存占用仅30MB左右。这个工具最初由GitHub工程师Will Glozer开发其核心特点是基于事件驱动架构使用LuaJIT和epoll/kqueue支持通过Lua脚本自定义测试逻辑极低的内存开销精确的延迟统计支持百分比分布注意wrk不适合做功能测试或复杂的场景测试它专注于HTTP协议层的性能基准测试。如果需要模拟用户操作流程建议结合JMeter等工具使用。2. 核心功能解析2.1 基础压力测试能力wrk的核心测试模式是通过简单的命令行参数配置即可完成基础压测wrk -t12 -c400 -d30s http://example.com/api这个命令启动了12个线程、400个连接持续测试30秒。在我的Dell XPS笔记本i7-1185G7上实测这样的配置可以产生约3.2万RPS的请求量。关键参数说明-t线程数建议设置为CPU核心数的2-4倍-c并发连接数注意不是QPS每个连接会串行处理请求-d测试持续时间--latency显示详细的延迟分布2.2 Lua脚本扩展wrk的真正威力在于其Lua脚本支持。通过脚本可以实现动态生成请求内容处理响应数据实现多阶段测试自定义认证逻辑一个典型的登录接口测试脚本示例-- auth_test.lua function init(args) local msg init with %s % {args[1] or default} print(msg) end request function() local headers {} headers[Content-Type] application/json local body {username:test,password:123456} return wrk.format(POST, /login, headers, body) end response function(status, headers, body) if status ~ 200 then print(Auth failed: ..body) end end使用时通过-s参数指定脚本wrk -t4 -c100 -d10s -s auth_test.lua http://api.example.com3. 性能测试实战指南3.1 测试环境搭建推荐使用Linux系统进行测试Windows性能会有10-20%损耗。以下是在Ubuntu 22.04上的安装步骤安装编译依赖sudo apt update sudo apt install -y build-essential libssl-dev git从源码编译安装git clone https://github.com/wg/wrk.git cd wrk make sudo cp wrk /usr/local/bin验证安装wrk --version3.2 典型测试场景场景1API基准测试wrk -t8 -c500 -d60s --latency http://api.example.com/v1/users重点关注输出中的Latency分布特别是99%和99.9%分位Requests/secQPSTransfer/sec带宽消耗场景2带参数的动态请求使用Lua脚本实现查询不同用户-- dynamic_query.lua user_ids {1001, 1002, 1003, 1004} request function() local uid user_ids[math.random(#user_ids)] local path /user/..uid return wrk.format(GET, path) end场景3混合读写测试模拟30%写请求、70%读请求的场景-- mixed_rw.lua function random_string(length) local res for i 1, length do res res .. string.char(math.random(97, 122)) end return res end request function() if math.random() 0.3 then -- 30%写请求 local body {namerandom_string(10), agemath.random(20,50)} local headers {[Content-Type]application/json} return wrk.format(POST, /users, headers, json.encode(body)) else -- 70%读请求 return wrk.format(GET, /users/..math.random(1000)) end end4. 结果分析与优化建议4.1 关键指标解读wrk的典型输出示例Running 1m test http://example.com 8 threads and 500 connections Thread Stats Avg Stdev Max /- Stdev Latency 254.05ms 356.97ms 1.99s 85.43% Req/Sec 401.25 342.68 1.70k 72.29% Latency Distribution 50% 105.47ms 75% 298.04ms 90% 724.80ms 99% 1.51s 191702 requests in 1.00m, 245.82MB read Requests/sec: 3194.34 Transfer/sec: 4.09MB需要重点关注的指标延迟分布特别是99分位值反映长尾延迟QPS波动通过Stdev值判断稳定性错误率未显示在默认输出中需要通过脚本统计4.2 性能瓶颈定位根据测试结果常见的优化方向案例1高延迟现象平均延迟500ms99分位2s可能原因后端服务处理能力不足检查CPU使用率数据库查询慢检查慢查询日志网络延迟测试ping值案例2低QPS现象Requests/sec低于预期排查步骤逐步增加并发连接数-c参数观察QPS变化如果QPS不增长可能是服务端线程池满检查服务端监控客户端成为瓶颈检查wrk进程CPU使用率带宽限制检查网络监控案例3错误率上升现象出现大量5xx或连接错误解决方案检查服务端错误日志降低测试强度找到系统稳定点检查连接池配置特别是Keep-Alive5. 高级技巧与陷阱规避5.1 保持连接复用默认情况下wrk会启用HTTP Keep-Alive。如果需要测试短连接场景可以在Lua脚本中设置wrk.headers[Connection] close重要提示保持连接复用能大幅提升测试效率。在我的测试中启用Keep-Alive可以使QPS提升3-5倍。5.2 避免测试偏差常见测试误区及解决方案冷启动偏差问题服务刚启动时性能不稳定方案先运行30秒预热测试不计入统计测试时长不足问题短时间测试无法反映GC等问题方案关键测试至少运行5分钟客户端瓶颈问题wrk本身成为性能瓶颈检查监控wrk进程的CPU使用率应接近100%5.3 分布式测试方案虽然wrk是单机工具但可以通过以下方式实现分布式测试使用Ansible并行执行# playbook.yml - hosts: load_agents tasks: - name: Run wrk test command: wrk -t4 -c1000 -d300s http://target-service async: 300 poll: 0结果聚合# 在各机器收集results.log后 awk /Requests\/sec/ {sum$2} END {print Total RPS:,sum} *.log6. 与其他工具对比6.1 wrk vs ab特性wrkab (ApacheBench)并发模型多线程epoll单进程多连接脚本支持Lua无延迟统计百分比分布仅平均值资源消耗低较高适用场景精准基准测试简单快速测试6.2 wrk vs JMeterJMeter更适合需要复杂场景模拟登录-操作-登出需要图形化结果分析测试非HTTP协议如JDBC、JMSwrk更适合需要高并发压测单机更高效率需要精确的延迟测量快速验证性能优化效果7. 生产环境实践心得在实际工作中我总结了以下最佳实践渐进式加压法从低并发开始逐步增加负载记录每个压力级别的性能指标找出性能拐点如QPS不再增长时混合场景测试不要只测试单一接口按照生产流量比例混合各类请求例如首页API:列表API:详情API 3:2:1监控联动在测试时同步监控服务端CPU/内存数据库负载网络带宽使用如Grafana等工具建立监控看板性能基线管理每次代码变更后运行相同的wrk测试建立性能变化曲线设置QPS/延迟的警戒阈值一个典型的监控联动方案# 在测试开始前启动监控 nohup sar -u 1 300 cpu.log nohup dstat -n 1 300 network.log # 运行wrk测试 wrk -t8 -c800 -d5m -s production_mix.lua http://service # 测试结束后分析监控数据 
长河君 · 2026/10/27 3:43:44 · 阅读 1.2k wrk HTTP基准测试工具：原理、实战与性能优化
1. 项目概述wrk是什么wrk是一款现代化的HTTP基准测试工具采用多线程设计能够高效地模拟高并发HTTP请求。与传统的abApacheBench或JMeter相比wrk在单机性能测试场景下展现出显著优势——在我的压力测试实践中一台普通开发机8核CPU使用wrk可以轻松产生5万 QPS的负载而内存占用仅30MB左右。这个工具最初由GitHub工程师Will Glozer开发其核心特点是基于事件驱动架构使用LuaJIT和epoll/kqueue支持通过Lua脚本自定义测试逻辑极低的内存开销精确的延迟统计支持百分比分布注意wrk不适合做功能测试或复杂的场景测试它专注于HTTP协议层的性能基准测试。如果需要模拟用户操作流程建议结合JMeter等工具使用。2. 核心功能解析2.1 基础压力测试能力wrk的核心测试模式是通过简单的命令行参数配置即可完成基础压测wrk -t12 -c400 -d30s http://example.com/api这个命令启动了12个线程、400个连接持续测试30秒。在我的Dell XPS笔记本i7-1185G7上实测这样的配置可以产生约3.2万RPS的请求量。关键参数说明-t线程数建议设置为CPU核心数的2-4倍-c并发连接数注意不是QPS每个连接会串行处理请求-d测试持续时间--latency显示详细的延迟分布2.2 Lua脚本扩展wrk的真正威力在于其Lua脚本支持。通过脚本可以实现动态生成请求内容处理响应数据实现多阶段测试自定义认证逻辑一个典型的登录接口测试脚本示例-- auth_test.lua function init(args) local msg init with %s % {args[1] or default} print(msg) end request function() local headers {} headers[Content-Type] application/json local body {username:test,password:123456} return wrk.format(POST, /login, headers, body) end response function(status, headers, body) if status ~ 200 then print(Auth failed: ..body) end end使用时通过-s参数指定脚本wrk -t4 -c100 -d10s -s auth_test.lua http://api.example.com3. 性能测试实战指南3.1 测试环境搭建推荐使用Linux系统进行测试Windows性能会有10-20%损耗。以下是在Ubuntu 22.04上的安装步骤安装编译依赖sudo apt update sudo apt install -y build-essential libssl-dev git从源码编译安装git clone https://github.com/wg/wrk.git cd wrk make sudo cp wrk /usr/local/bin验证安装wrk --version3.2 典型测试场景场景1API基准测试wrk -t8 -c500 -d60s --latency http://api.example.com/v1/users重点关注输出中的Latency分布特别是99%和99.9%分位Requests/secQPSTransfer/sec带宽消耗场景2带参数的动态请求使用Lua脚本实现查询不同用户-- dynamic_query.lua user_ids {1001, 1002, 1003, 1004} request function() local uid user_ids[math.random(#user_ids)] local path /user/..uid return wrk.format(GET, path) end场景3混合读写测试模拟30%写请求、70%读请求的场景-- mixed_rw.lua function random_string(length) local res for i 1, length do res res .. string.char(math.random(97, 122)) end return res end request function() if math.random() 0.3 then -- 30%写请求 local body {namerandom_string(10), agemath.random(20,50)} local headers {[Content-Type]application/json} return wrk.format(POST, /users, headers, json.encode(body)) else -- 70%读请求 return wrk.format(GET, /users/..math.random(1000)) end end4. 结果分析与优化建议4.1 关键指标解读wrk的典型输出示例Running 1m test http://example.com 8 threads and 500 connections Thread Stats Avg Stdev Max /- Stdev Latency 254.05ms 356.97ms 1.99s 85.43% Req/Sec 401.25 342.68 1.70k 72.29% Latency Distribution 50% 105.47ms 75% 298.04ms 90% 724.80ms 99% 1.51s 191702 requests in 1.00m, 245.82MB read Requests/sec: 3194.34 Transfer/sec: 4.09MB需要重点关注的指标延迟分布特别是99分位值反映长尾延迟QPS波动通过Stdev值判断稳定性错误率未显示在默认输出中需要通过脚本统计4.2 性能瓶颈定位根据测试结果常见的优化方向案例1高延迟现象平均延迟500ms99分位2s可能原因后端服务处理能力不足检查CPU使用率数据库查询慢检查慢查询日志网络延迟测试ping值案例2低QPS现象Requests/sec低于预期排查步骤逐步增加并发连接数-c参数观察QPS变化如果QPS不增长可能是服务端线程池满检查服务端监控客户端成为瓶颈检查wrk进程CPU使用率带宽限制检查网络监控案例3错误率上升现象出现大量5xx或连接错误解决方案检查服务端错误日志降低测试强度找到系统稳定点检查连接池配置特别是Keep-Alive5. 高级技巧与陷阱规避5.1 保持连接复用默认情况下wrk会启用HTTP Keep-Alive。如果需要测试短连接场景可以在Lua脚本中设置wrk.headers[Connection] close重要提示保持连接复用能大幅提升测试效率。在我的测试中启用Keep-Alive可以使QPS提升3-5倍。5.2 避免测试偏差常见测试误区及解决方案冷启动偏差问题服务刚启动时性能不稳定方案先运行30秒预热测试不计入统计测试时长不足问题短时间测试无法反映GC等问题方案关键测试至少运行5分钟客户端瓶颈问题wrk本身成为性能瓶颈检查监控wrk进程的CPU使用率应接近100%5.3 分布式测试方案虽然wrk是单机工具但可以通过以下方式实现分布式测试使用Ansible并行执行# playbook.yml - hosts: load_agents tasks: - name: Run wrk test command: wrk -t4 -c1000 -d300s http://target-service async: 300 poll: 0结果聚合# 在各机器收集results.log后 awk /Requests\/sec/ {sum$2} END {print Total RPS:,sum} *.log6. 与其他工具对比6.1 wrk vs ab特性wrkab (ApacheBench)并发模型多线程epoll单进程多连接脚本支持Lua无延迟统计百分比分布仅平均值资源消耗低较高适用场景精准基准测试简单快速测试6.2 wrk vs JMeterJMeter更适合需要复杂场景模拟登录-操作-登出需要图形化结果分析测试非HTTP协议如JDBC、JMSwrk更适合需要高并发压测单机更高效率需要精确的延迟测量快速验证性能优化效果7. 生产环境实践心得在实际工作中我总结了以下最佳实践渐进式加压法从低并发开始逐步增加负载记录每个压力级别的性能指标找出性能拐点如QPS不再增长时混合场景测试不要只测试单一接口按照生产流量比例混合各类请求例如首页API:列表API:详情API 3:2:1监控联动在测试时同步监控服务端CPU/内存数据库负载网络带宽使用如Grafana等工具建立监控看板性能基线管理每次代码变更后运行相同的wrk测试建立性能变化曲线设置QPS/延迟的警戒阈值一个典型的监控联动方案# 在测试开始前启动监控 nohup sar -u 1 300 cpu.log nohup dstat -n 1 300 network.log # 运行wrk测试 wrk -t8 -c800 -d5m -s production_mix.lua http://service # 测试结束后分析监控数据