wrk是一款开源的HTTP基准测试工具，特点是线程模型轻量、单机就能打出非常高的压力，常用来测试Nginx、OpenResty、Node.js等Web服务的吞吐能力。相比老牌的ab，wrk支持多线程和多连接复用，测试结果也更加直观。本文以腾讯云CVM云服务器为环境，从安装部署到压测执行再到结果解读，完整走一遍Web性能评测的流程。
一、在腾讯云CVM上安装wrk
wrk本身没有提供预编译的二进制包，一般通过源码编译安装。先登录腾讯云CVM控制台，确认安全组已经放行了SSH所需的22端口以及被测Web服务的端口（比如80或8080）。接着SSH登录服务器，安装编译依赖。以CentOS为例：
# 安装编译工具和依赖 yum install -y epel-release yum install -y git gcc make openssl-devel # 克隆源码并编译 cd /usr/local/src git clone https://github.com/wg/wrk.git cd wrk make # 将可执行文件复制到系统路径 cp wrk /usr/local/bin/ wrk --version
Ubuntu系统则把yum换成apt即可，依赖包为build-essential、git和libssl-dev。编译完成后执行wrk --version，如果输出类似wrk 1.2.1的版本号，说明安装成功。需要注意的是，wrk依赖系统的 OpenSSL 库来支持HTTPS测试，如果缺少openssl-devel，编译时会报openssl/ssl.h: No such file or directory这样的错误。
另外提醒一点，压测机和被测服务建议分开部署在两台CVM上，而且两台机器最好处于同一个地域和可用区，内网互通，这样能排除公网带宽对测试结果的干扰。如果条件允许，选择腾讯云同一私有网络（VPC）下的两台CVM，通过内网IP互相访问，测出来的数据才更接近服务本身的处理能力。
二、wrk核心参数与压测执行
wrk的命令行参数不多，但每个都很关键。常用参数含义如下：
-t：使用的线程数，一般设置为CPU核心数的1到2倍-c：并发连接总数，必须大于等于线程数-d：测试持续时间，如30s、2m-s：指定Lua脚本，用于自定义请求-H：添加自定义请求头--latency：输出更详细的延迟分布数据--timeout：设置超时时间，默认2秒
一个典型的压测命令是这样的：
# 对目标服务进行30秒压测，12个线程，400个并发连接 wrk -t12 -c400 -d30s --latency http://10.0.8.16:8080/index.html
执行后wrk会输出压测结果，主要包括三部分：请求统计（总请求数、每秒请求数、传输数据量）、延迟分布（平均值、标准差、最大值以及正态分布的百分位数据）和Socket统计（连接失败、读取失败、写入失败等）。结果中最重要的两个指标是Requests/sec（QPS）和Latency分布。
解读延迟数据时要重点关注P99.9甚至P99.99分位。平均值好看不代表用户体验好，如果平均值是5毫秒但P99.9达到500毫秒，说明有相当一部分请求体验很差，通常是GC停顿、连接池耗尽或者锁竞争造成的。延迟分布的格式类似50% 3.2ms / 75% 4.1ms / 90% 6.8ms，表示50%的请求在3.2毫秒内完成，90%的请求在6.8毫秒内完成。
三、用Lua脚本模拟真实请求
直接用命令行压测只能发送简单的GET请求，真实业务中往往需要带自定义Header、Cookie或者POST请求体，这时候就要借助wrk的Lua脚本能力。wrk内置了几个可挂钩的函数，最常用的是setup（每个线程初始化时调用）和request（每次发起请求前调用）。
下面是一个模拟POST接口请求的脚本示例：
-- post_test.lua
wrk.headers["Content-Type"] = "application/json"
wrk.headers["Authorization"] = "Bearer test-token-123"
request = function()
local body = string.format('{"userId":%d,"action":"view"}', math.random(1, 10000))
return wrk.format("POST", "/api/track", nil, body)
end执行时通过-s参数加载脚本：
wrk -t8 -c200 -d60s -s post_test.lua --latency http://10.0.8.16:8080
如果需要每个请求访问不同的URL，可以在request函数里用wrk.format动态拼接路径，比如从预先生成的URL列表中随机取一个。如果需要统计业务层面的状态码，可以在response函数里累计变量，在done函数里输出统计结果。这种脚本化的能力让wrk不只是一个简单的压测工具，而是可以模拟出接近真实业务模型的流量。
四、压测结果分析与常见问题
拿到数据后不要只看QPS一个数字，要结合延迟分布、错误数量和系统资源情况综合判断。压测期间建议开另一个终端用top、vmstat、iostat观察被测服务器的CPU、内存和磁盘IO，同时检查压测机自身的负载。如果压测机CPU已经跑满，那么测出的QPS是压测机的瓶颈而不是服务器的瓶颈，此时应该提高单机压测能力或者采用多台CVM分布式压测。
常见的异常情况有几种：Non-2xx or 3xx responses数量很大，说明服务返回了错误，先检查应用日志；Socket errors: connect较多，可能是被测服务的连接数限制（如Nginx的worker_connections）或者系统fd数量不够，可以通过ulimit -n调大文件描述符上限；延迟随时间持续增长，则要怀疑后端连接池耗尽或者内存泄漏。
关于腾讯云CVM的实例规格选择，做压测时被测服务器建议选用计算型或标准型实例，注意云主机的网络带宽和PPS（每秒包数量）是有上限的，如果压测目标是静态页面且QPS极高，瓶颈可能出在实例的带宽配额上而不是应用本身，此时可以在控制台调高带宽峰值再对比测试结果，避免得出错误结论。压测完成后记得清理测试脚本和临时服务，涉及公网压测还要遵守相关法律法规，只对自有业务进行测试。
总结一下，wrk配合腾讯云CVM可以快速搭建一套轻量的Web性能评测环境。关键是掌握好线程与连接数的配比、学会用Lua脚本模拟真实流量，并且能够从延迟分位数和系统资源两个维度去解读数据，这样才能真正定位出Web服务的性能瓶颈，为后续的容量规划和优化提供可靠依据。