Web服务上线之前，性能压测几乎是绕不开的环节。腾讯云CVM作为最常用的云服务器产品，购买之后到底能扛多少QPS、延迟表现如何，光看CPU和内存参数是估算不出来的，必须用真实流量模拟工具来验证。wrk正是做这件事的利器，它体积小、安装简单、单机就能打出非常高的并发压力，比ab这类老牌工具更适合现代多核服务器环境。本文以一台腾讯云CVM为例，从安装部署、基础压测、指标解读到进阶用法，完整走一遍Web性能评测流程。
一、wrk是什么，为什么选它做压测
wrk是一款开源的HTTP基准测试工具，用C语言编写，核心特点是结合了多线程与epoll事件驱动模型。传统工具如ab采用多进程或阻塞式IO，单实例往往打不满现代服务器的网络与CPU资源，而wrk只需要少量线程就能维持成千上万的并发连接，压测机本身的资源消耗很低，测出来的数据更接近服务端的真实上限。
wrk自带一个可选的LuaJIT脚本引擎，可以通过编写Lua脚本自定义请求内容，比如带随机参数、带Cookie、实现POST提交等，这一点在实际业务压测中非常实用。它的输出结果也很精炼，直接给出延迟分布、吞吐量和Socket错误统计，不需要额外做复杂数据处理。
当然wrk也有局限：它只支持HTTP协议，不支持HTTP/2的服务器推送等新特性测试，也没有图形化报告。如果需要更复杂的场景编排，可以再考虑JMeter或Locust，但在纯吞吐量基准测试这个场景下，wrk依然是最轻快的选择。
二、在腾讯云CVM上安装wrk并准备压测环境
准备两台CVM最理想：一台作为压测机运行wrk，另一台作为被测机部署Web服务（比如Nginx）。两台机器放在同一个地域的同一个可用区、使用内网互访，可以排除公网带宽对结果的干扰。如果只有一台机器，也可以本机压本机，但数据会受CPU争抢影响，仅供粗略参考。
以CentOS 7或OpenCloudOS为例，安装wrk前先装依赖，然后从GitHub克隆源码编译：
# 安装编译依赖 yum install -y git gcc make openssl-devel # 克隆并编译wrk git clone https://github.com/wg/wrk.git cd wrk make # 将可执行文件放入PATH cp wrk /usr/local/bin/ wrk --version
Ubuntu或Debian系统更简单，直接执行apt install wrk即可，仓库里的版本虽然不是最新，用于基准测试完全够用。
被测端建议部署Nginx并输出一个静态测试页面。压测前务必检查两点：第一，腾讯云安全组要放行压测机到被测机80端口的内网流量；第二，如果并发连接数很高，需要先调大被测机的连接队列和文件句柄限制，否则测到的可能是内核配置瓶颈而不是Web服务性能。参考配置如下：
# 被测机内核参数调整 echo "net.core.somaxconn = 65535" >> /etc/sysctl.conf echo "net.ipv4.tcp_max_syn_backlog = 65535" >> /etc/sysctl.conf sysctl -p # 提升文件句柄上限 ulimit -n 65535
压测机同样需要放开ulimit -n限制，并适当调低本地端口耗尽的影响，例如开启net.ipv4.tcp_tw_reuse。这些准备工作做好后，测出来的数据才具备可比性。
三、wrk基础用法与关键参数详解
wrk的命令格式非常简洁，一条命令就能发起压测：
wrk -t8 -c1000 -d60s --latency http://10.0.1.20:80/index.html
参数含义分别是：-t指定线程数，一般设为压测机CPU核心数的1到2倍即可，线程再多意义不大；-c指定总并发连接数，注意wrk要求连接数不小于线程数；-d指定压测持续时间，建议至少60秒，过短的数据容易被TCP慢启动影响；--latency用于输出更详细的延迟分布统计。
典型输出结果如下：
Running 1m test @ http://10.0.1.20:80/index.html
8 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.35ms 5.20ms 210.00ms 92.10%
Req/Sec 1.02k 98.30 1.95k 88.50%
Latency Distribution
50% 11.20ms
75% 14.80ms
90% 18.50ms
99% 32.60ms
1352410 requests in 60.00s, 350.50MB read
Requests/sec: 22540.17
Transfer/sec: 5.84MB解读几个核心指标：Requests/sec就是常说的QPS，是吞吐量的直接体现；Latency Distribution中的50%、99%分位数分别代表一半和99%的请求延迟低于该值，评估用户体验时99分位比平均值重要得多；末尾如果没有出现Socket errors统计，说明压测期间没有连接失败，数据有效。如果出现大量connect错误，通常是文件句柄不足或安全组拦截；出现read或timeout错误，则多半是服务端过载或内核队列打满，需要结合被测机的CPU、负载和Nginx错误日志一起分析。
四、用Lua脚本模拟真实业务与进阶技巧
静态页面压测只能反映网络与内核转发能力，实际业务大多是带参数的动态请求。wrk通过Lua脚本可以灵活定制每个请求，下面这个脚本演示了随机参数URL和POST请求体的写法：
-- 文件名: post_test.lua
-- 每个线程初始化时执行一次
function thread_init(thread)
wrk.thread_id = thread.id
end
-- 每次请求生成随机ID
request = function()
local id = math.random(1, 1000000)
local path = "/api/query?id=" .. id
return wrk.format("GET", path)
end
-- 如需POST请求可以这样写
-- request = function()
-- local body = '{"user":"test"}'
-- return wrk.format("POST", "/api/login", nil, body)
-- end执行时通过-s参数加载脚本：
wrk -t8 -c500 -d120s -s post_test.lua --latency http://10.0.1.20:80/
另一个进阶技巧是阶梯式加压。不要一上来就打满并发，而是从100、500、1000、2000逐级递增，每级持续一段时间，观察QPS和99分位延迟的变化曲线。通常QPS会随并发上升，到某个点后趋于平稳甚至下降，而99分位延迟开始陡增，这个拐点就是服务的实际承载能力，比单点压测一个固定并发更有参考价值。
如果需要横向评估不同规格的CVM，保持Nginx配置、内核参数、测试页面完全一致，只更换实例规格（例如2核4G对比4核8G），分别记录拐点QPS与延迟，就能得到很有说服力的规格选型依据。压测过程中可以同时在被测机用top、vmstat观察资源占用，确认瓶颈到底在CPU、磁盘IO还是网络。
五、压测常见误区与注意事项
第一个常见误区是公网压内网。有些人在自己的电脑上直接压腾讯云服务器公网IP，结果带宽限额先被打满，测出来的QPS实际是公网带宽瓶颈，和服务器性能无关。正式评测一定要走内网。
第二个误区是忽视压测机自身瓶颈。wrk虽然高效，但当并发达到数万时，压测机的CPU、端口数、文件句柄同样会到达极限。如果发现压测机CPU已经跑满而服务端还很空闲，说明压力没打够，需要更换更高配置的压测机或者分布式多机压测。
第三，压测数据要多次取平均。单次测试会受瞬时抖动影响，建议相同参数至少跑三次，取中位数结果。同时记录被测机的监控数据（可借助腾讯云可观测平台的CPU利用率、带宽和连接数曲线），与wrk输出互相印证，这样得到的评测报告才经得起推敲。压测完成后记得清理测试脚本和放开的安全组规则，避免给线上环境留下隐患。