把一台Web服务器部署到华为云ECS之后，它到底能扛多少并发、每秒能处理多少请求、延迟表现如何，这些问题光靠猜测没有意义，必须通过规范的压测来回答。wrk是一款基于多线程和epoll事件驱动的HTTP基准测试工具，单机就能打出数十万QPS的压力，非常契合云服务器环境。本文以一次完整的评测流程为主线，覆盖环境准备、工具安装、测试设计、结果分析四个阶段，帮你把性能摸得清清楚楚。
测试前的环境准备与实例选型
压测结果是否可信，很大程度上取决于测试环境是否干净、规格是否明确。首先在华为云控制台购买ECS实例时，建议明确记录vCPU型号、内存大小、镜像版本和带宽上限，这些参数直接影响后续对结果的解释。比如2vCPU的实例，如果压测打出了100%的CPU占用，那说明瓶颈在计算资源，而不是Web服务本身。
操作系统推荐选择Ubuntu 22.04或CentOS系的较新版本，内核自带的网络栈已经比较完善。测试前先更新系统并安装编译工具链，因为wrk需要从源码编译：
# Ubuntu/Debian sudo apt update sudo apt install -y build-essential git libssl-dev # CentOS/OpenEuler sudo yum install -y gcc git make openssl-devel
另外一个容易被忽视的点是文件描述符限制。wrk在高并发下会打开大量连接，默认的1024限制远远不够，需要调整ulimit -n 65535，或者在/etc/security/limits.conf中永久放宽。同时，如果被测服务和压测工具跑在同一台ECS上，两者会互相争抢CPU资源，结果会明显失真，条件允许时建议准备两台同可用区的ECS，一台部署Web服务，一台专门跑wrk。
wrk的安装与核心参数详解
wrk的安装非常简单，克隆源码后编译即可，编译产物就是一个独立的二进制文件：
git clone https://github.com/wg/wrk.git cd wrk make sudo cp wrk /usr/local/bin/ wrk --version # 验证安装
wrk的命令行参数不多，但每个都直接影响测试行为。-t指定线程数，一般设置为vCPU核数的1到2倍即可，过多线程反而增加调度开销；-c指定并发连接总数，必须大于等于线程数；-d指定持续时间，建议至少60秒，太短的测试容易被TCP慢启动和缓存预热影响；-t配合-c的组合决定了每个线程分到的连接数。此外--timeout设置单请求超时时间，-H可以添加自定义请求头，比如模拟真实浏览器带上User-Agent或Cookie。
一个基础的压测命令如下：
wrk -t4 -c200 -d60s --timeout 5s http://192.168.0.10:8080/
这条命令表示用4个线程维持200个并发连接，持续压测60秒。输出结果中重点关注四个指标：Requests/sec是吞吐量，Latency各分位值反映响应速度，Socket errors统计连接异常数量，Non-2xx统计非成功响应。如果出现大量socket错误，往往是服务端连接被拒绝或者带宽被打满，此时数据不可信，需要先排查再重测。
用Lua脚本模拟真实请求与进阶测试
默认的wrk只会反复请求同一个URL，这和真实业务差距很大。wrk支持Lua脚本定制每个连接建立、每次请求发送时的行为，包括动态修改路径、POST请求体等。下面是一个简单的POST示例：
-- post.lua 动态POST请求脚本
wrk.method = "POST"
wrk.body = '{"username":"user","password":"pass"}'
wrk.headers["Content-Type"] = "application/json"
request = function()
local uid = math.random(1, 100000)
wrk.body = string.format('{"uid":%d}', uid)
return wrk.format(nil, "/api/query")
end
wrk -t4 -c200 -d60s -s post.lua http://192.168.0.10:8080/
脚本中的request函数在每次发起请求时被调用，可以借助math.random或预置的URL列表实现请求打散，避免全部命中缓存导致数据虚高。如果需要统计自定义指标，比如只统计业务成功响应的延迟，可以使用response回调配合done回调输出汇总结果。
另一个进阶场景是长连接测试。现代Web服务几乎都默认开启HTTP Keep-Alive，wrk默认也是复用连接的；如果要验证短连接场景，可以在脚本里设置wrk.headers["Connection"] = "close"，对比两种模式下的QPS差异，这个差异能反映服务端连接建立的开销。还可以用--latency参数输出完整的延迟分布直方图，观察P99、P999等长尾指标，对评估用户体验非常有价值。
结果分析与瓶颈定位
拿到wrk的输出后，不要急着下结论，先结合华为云控制台的云监控数据交叉验证。在压测期间观察ECS实例的CPU使用率、内存占用、网络出流量和入流量曲线。如果CPU先到瓶颈，说明计算资源不足，可以考虑升级实例规格或开启Web服务的多进程模式；如果带宽先跑满（比如购买的是5Mbit/s固定带宽，流量曲线长期顶在约0.6MB/s），那QPS再高也被网络卡住，此时测的是带宽而非服务能力。
对比测试是评测中最有价值的部分。建议整理一张表格记录不同场景的数据：并发100、500、1000下的QPS和P99延迟，短连接与长连接的差异，静态页面与动态API的差异。例如一次典型测试中，Nginx静态页在4vCPU实例上可达4万以上QPS，而走数据库查询的动态接口可能只有2000QPS，两者相差一个数量级，这种对比能直接指导容量规划。
最后提醒几个常见误区：一是在公网IP上压测，结果受公网带宽和运营商网络抖动影响很大，应尽量使用内网IP或弹性公网IP大带宽模式；二是只测一次就出报告，任何严肃的评测都应重复至少三次取中位数；三是忽略压测机自身的瓶颈，wrk所在机器CPU如果接近100%，压测压力就到头了，再提高连接数只会让数据变差。把这几个细节控制好，一份有说服力的华为云ECS Web性能评测报告就基本成型了。