wrk是一款基于异步IO模型的开源HTTP基准测试工具，凭借出色的并发能力和极低的资源占用，被广泛用于评估Web服务器、API网关以及各类后端服务的性能表现。在Azure云平台上，虚拟机的网络性能、磁盘IO和CPU配置都会直接影响压测结果的准确性，因此在Azure虚拟机上科学地使用wrk进行评测，是很多运维和开发人员关心的问题。本文将从环境搭建、参数详解、脚本定制和结果解读四个方面，完整介绍整个评测流程。
一、评测前的环境准备与虚拟机选型
在Azure上做性能评测，首先要明确压测机和被测机的角色划分。如果条件允许，建议准备两台虚拟机：一台作为压力发起端运行wrk，另一台作为被测的Web服务器，两台机器放在同一个虚拟网络甚至同一个可用区内，避免公网链路抖动污染数据。
虚拟机规格的选择直接影响wrk的并发能力。wrk本身非常轻量，一台2核4GB的B2ms规格即可轻松发起数万并发连接，但如果要模拟持续高负载，建议选择D系列通用型（如D4s_v5），其网络带宽和CPU稳定性更有保障。被测端的规格则要根据业务目标来定，同时注意Azure虚拟机的网络带宽与vCPU数量绑定，小规格机器可能先于应用达到网络瓶颈。
操作系统方面，Linux发行版（如Ubuntu 22.04）编译wrk最为方便。如果你的Web服务部署在Windows Server上，压测端依然推荐使用Linux虚拟机运行wrk，避免Windows端工具链的额外复杂度。被测端如果涉及Windows路径配置，例如IIS站点日志在C:\inetpub\logs目录下，检查日志增长情况也有助于分析压测期间的状态。
二、在Azure虚拟机上安装和编译wrk
wrk没有提供官方的预编译二进制包，需要在Linux上自行编译。以Ubuntu为例，先安装编译依赖，然后从GitHub克隆源码编译：
# 安装编译所需的工具和依赖库 sudo apt update sudo apt install -y build-essential git libssl-dev # 克隆wrk源码并编译 git clone https://github.com/wg/wrk.git cd wrk make # 将编译产物加入可执行路径 sudo cp wrk /usr/local/bin/ wrk --version
编译成功后执行wrk --version能看到版本号即说明安装完成。如果编译时报缺少pthread相关错误，通常是build-essential未安装完整，重新执行依赖安装命令即可。整个过程通常不超过两分钟，这也是wrk相比许多重量级压测工具的优势之一。
对于必须在Windows环境下工作的场景，可以考虑在Windows 10及以上系统上启用WSL（适用于Linux的Windows子系统），在WSL内的Ubuntu环境中按上述步骤编译wrk。需要注意WSL2的网络经过一层虚拟化转发，发起超高并发时性能会打折扣，正式评测仍建议使用原生Linux虚拟机。
三、wrk核心参数与Lua脚本定制
wrk的基本命令格式为wrk [选项] URL，最常用的一次完整压测命令如下：
# 使用2个线程、500个并发连接，持续压测60秒 wrk -t2 -c500 -d60s --latency http://10.0.1.20:8080/index.html
其中-t指定线程数，一般设置为CPU核数或其两倍即可，线程数并非越大越好；-c指定并发连接总数，必须不小于线程数；-d指定压测时长；--latency用于输出详细的延迟分布（P50、P75、P90、P99）。此外还有-s参数可以加载自定义Lua脚本，实现带参数请求、POST请求或动态Header等复杂场景。
下面是一个使用Lua脚本发送POST请求的例子，常用于压测REST API：
-- post_test.lua：构造POST请求体和请求头
wrk.method = "POST"
wrk.body = '{"username":"test","action":"query"}'
wrk.headers["Content-Type"] = "application/json"
-- 每个线程启动前执行一次，可做初始化
function setup(thread)
thread:set("id", 1)
end
-- 每次请求前执行，可用于修改请求
function request()
return wrk.format(nil, nil, nil, wrk.body)
end通过wrk -t2 -c200 -d30s -s post_test.lua http://10.0.1.20:8080/api/user即可对API进行压测。Lua脚本的灵活之处在于还可以在response回调中统计非2xx响应数量，从而过滤掉压测过程中出现的业务错误。
四、压测结果解读与常见误区
一次典型的wrk输出包含三部分数据：延迟分布（Latency）、请求速率（Requests/sec）和传输速率（Transfer/sec）。重点关注的指标包括P99延迟，它反映了长尾用户体验；以及Requests/sec吞吐量，它体现服务器在当前并发下的处理上限。Socket errors部分的connect错误通常意味着被测端 backlog 队列溢出或端口耗尽，read/write错误则可能与超时或连接重置有关。
解读结果时要结合Azure门户中虚拟机的监控指标一起看。压测期间如果CPU百分比长期接近100%，说明是计算瓶颈；如果CPU很闲但吞吐量上不去，需要检查网络出入速率是否触发了虚拟机规格的带宽上限，或者应用内部是否存在锁竞争。Linux被测端还可以用sar、vmstat等工具观察上下文切换和软中断情况。
最后提醒几个常见误区：一是压测时长过短，30秒以内的结果往往包含冷启动误差，建议至少持续1到5分钟；二是只测一次就下结论，应多次运行取稳定区间；三是在同一台机器上既跑wrk又跑被测服务，两者会互相争抢CPU导致数据失真；四是忽略客户端的文件描述符限制，Linux上可用ulimit -n 65536临时调大，否则高并发时wrk自身会先报错。避开这些坑，才能得到一份可信的Azure虚拟机Web性能评测报告。