企业官网建设流程全解析

1. 项目概述：为什么我们需要wrk？

在服务器端开发、API接口设计或者微服务架构的日常工作中，一个绕不开的话题就是性能。你的服务上线前，总得心里有数：它到底能扛住多少并发？响应时间在压力下会变成什么样？会不会在某个临界点突然崩溃？这些问题，靠“感觉”或者简单的浏览器刷新是远远不够的，你需要一个趁手的“压力测试”工具，来模拟真实用户的高并发访问，把服务的性能瓶颈和潜在问题暴露在可控的环境下。

市面上性能测试工具不少，从老牌的Apache JMeter、LoadRunner，到新潮的k6、Gatling，各有千秋。但如果你追求的是极致的轻量、高效和开发友好，特别是在Linux环境下，那么wrk绝对是一个无法忽视的选择。我第一次接触wrk，是在为一个高并发的实时推送服务做压测选型时。当时用JMeter模拟上千个长连接，资源消耗巨大，测试机自己先扛不住了。换用wrk后，用同样的机器，它能轻松发起数万个连接，并且CPU和内存占用率低得惊人，脚本编写还特别简单直观——用LuaJIT写几行逻辑就能定制复杂的测试场景。从那以后，wrk就成了我性能工具箱里的常备利器。

简单来说，wrk是一个用C语言编写的现代HTTP基准测试工具。它之所以能在一众工具中脱颖而出，核心在于其“多线程+事件驱动”的架构。它利用操作系统的高性能I/O模型（如Linux下的epoll），让单个线程就能处理成千上万个网络连接，再通过多线程来充分利用多核CPU。这意味着，wrk可以用很少的系统资源，产生巨大的HTTP请求压力，特别适合用来探测服务的极限性能。对于后端开发者、运维工程师和测试人员而言，掌握wrk，就等于拥有了一把直接度量服务吞吐量、延迟和稳定性的标尺。无论是快速验证一个优化是否有效，还是进行正式的容量规划，wrk都能提供可靠的数据支撑。

2. wrk的核心优势与适用场景解析

2.1 对比主流工具，wrk强在哪里？

在决定深入使用一个工具前，搞清楚它的定位和比较优势很重要。我们不妨把wrk和几个常见的对手放在一起看看。

vs Apache JMeter：JMeter是功能全面的“瑞士军刀”，图形化界面、丰富的协议支持（HTTP, JDBC, JMS等）、完善的监听器和报告。但它也是著名的“重量级”选手，作为Java应用，其自身资源开销较大。当需要模拟非常高并发（比如数万连接）时，JMeter测试机本身容易成为瓶颈。wrk则像一把“手术刀”，专注HTTP/HTTPS基准测试，极致轻量，资源利用率高，适合做极限压测和快速测试。通常，我会用JMeter做复杂业务场景、阶梯加压的综合性测试，而用wrk做单接口的极限吞吐量和延迟摸底。

vs ab (ApacheBench)：ab可能是很多人最早接触的压测工具，简单易用。但ab功能非常基础，不支持连接复用（HTTP Keep-Alive）下的持续压测模式是硬伤，而且其单进程模型性能上限较低。wrk天然支持连接池和Keep-Alive，性能远超ab，并且通过Lua脚本可以实现参数化、结果定制等高级功能。

vs k6 / Gatling：这两者是新一代以代码（JavaScript/Scala）为核心的性能测试工具，特别适合集成到CI/CD流程中。它们功能强大，报告美观。但相比之下，wrk更底层、更“裸奔”，不依赖额外的运行时（如Node.js或JVM），部署简单，性能损耗更小。如果你需要的是一个能榨干服务器性能、反映最真实网络处理能力的基准工具，wrk往往是更纯粹的选择。

总结wrk的核心优势：

1. 高性能与低开销：多线程+事件驱动架构，能用少量资源产生巨大压力。
2. 灵活可编程：内嵌LuaJIT，允许在压测的不同阶段（请求生成、响应处理、结果报告）注入自定义逻辑。
3. 简单易用：基础命令行参数直观，上手极快，适合快速测试。
4. 数据准确：专注于HTTP基准测试，结果（如延迟分布）通常被认为非常可靠。

2.2 wrk的典型应用场景

理解了优势，我们来看看wrk具体能在哪些地方发挥作用：

1. API接口性能基准测试：这是最常用的场景。开发完一个新接口，用wrk快速跑一下，得到QPS（每秒查询率）、平均响应时间、延迟分布（如P99）等关键指标，建立性能基线。
2. 性能回归测试：在代码优化、框架升级或配置调整后，用相同的wrk脚本和参数再次测试，对比优化前后的数据，量化改进效果。比如，你调整了Nginx的worker_connections参数，用wrk一压便知是否有提升。
3. 容量规划与瓶颈探测：逐步增加wrk的并发连接数和线程数，观察服务的QPS曲线和错误率。当QPS不再增长或错误率飙升时，就找到了当前部署下的性能瓶颈。结合监控（如CPU、内存、I/O），可以判断瓶颈是在应用代码、数据库还是网络。
4. 微服务链路压测：虽然wrk是单点压测工具，但可以通过编写Lua脚本，模拟复杂的微服务调用链（如先登录获取token，再用token访问其他接口），来测试网关或核心链路的性能。
5. 中间件性能对比：例如，对比不同Web服务器（Nginx vs OpenResty）或不同框架（Spring Boot vs Quarkus）在相同硬件和请求模式下的性能差异。

注意：wrk是一个“基准测试”工具，它倾向于在短时间内施加最大压力，以获取系统极限性能数据。它并不完全等同于模拟真实用户行为、有思考时间、逐步加压的“负载测试”或“压力测试”。对于后者，可能需要结合JMeter、k6等工具，或者用wrk的Lua脚本实现简单的思考时间逻辑。

3. 从零开始：wrk的安装与编译

wrk的安装不像apt install那么简单直接，因为它通常不包含在主流Linux发行版的默认软件仓库中。我们需要从源码编译安装。别担心，这个过程其实很 straightforward。

3.1 系统环境准备与依赖安装

wrk依赖两个核心库：OpenSSL（用于HTTPS支持）和LuaJIT（用于脚本支持）。在编译前，我们需要确保系统已经安装了它们的开发包。

对于基于Debian/Ubuntu的系统：

sudo apt update sudo apt install -y build-essential libssl-dev git

• build-essential：提供了gcc、make等编译工具链。
• libssl-dev：OpenSSL的开发库，头文件和链接库。
• git：用于从代码仓库克隆wrk源码。

对于基于RHEL/CentOS/Fedora的系统：

sudo yum groupinstall -y "Development Tools" sudo yum install -y openssl-devel git # 或者使用 dnf (Fedora, CentOS 8+) # sudo dnf groupinstall -y "Development Tools" # sudo dnf install -y openssl-devel git

至于LuaJIT，wrk的源码仓库里已经包含了一个特定版本的LuaJIT源码，在编译时会自动构建，所以一般不需要单独安装系统级的LuaJIT。这是一种常见的“vendored dependency”做法，能确保wrk使用一个已知兼容的LuaJIT版本。

3.2 源码获取、编译与安装

1. 克隆仓库：使用git克隆官方仓库（或你信任的镜像仓库）。

   git clone https://github.com/wg/wrk.git cd wrk

   我习惯先cd到一个工作目录，比如~/tools/，再执行克隆。

2. 执行编译：wrk使用标准的make进行构建。

   make

   这个命令会做以下几件事：

   • 进入deps目录，编译LuaJIT。
   • 编译wrk自身的C源码。
   • 将编译好的LuaJIT静态库与wrk链接。

   如果一切顺利，你会在当前目录下看到名为wrk的可执行文件。编译过程通常很快，十几秒到一分钟内完成。

3. 验证安装：编译完成后，可以直接在当前目录运行./wrk --version来验证。但为了使用方便，我们通常将其安装到系统路径。

4. 安装到系统（可选但推荐）：

   sudo cp wrk /usr/local/bin/

   现在，你可以在任何位置直接使用wrk命令了。再次验证：

   wrk --version

   如果输出类似wrk 4.2.0 [epoll] Copyright (C) 2012 by Will Glozer的信息，恭喜你，安装成功！括号里的[epoll]表明它使用的是Linux的高性能I/O事件通知机制。

实操心得与避坑指南：

• 编译错误“找不到openssl/ssl.h”：这几乎肯定是libssl-dev或openssl-devel没装好。请重新检查上一步的依赖安装命令，并确保包管理器的源是更新的。
• 性能考量：默认的make会使用-O2优化级别。如果你在极其追求性能的测试环境，可以尝试修改Makefile中的CFLAGS，加入-O3 -march=native等更激进的优化选项，但这对最终压测结果的影响微乎其微，通常没必要。
• 多版本管理：如果你需要测试不同版本的wrk，不建议直接覆盖/usr/local/bin/wrk。可以将其重命名为wrk-4.2.0，然后通过软链接ln -s来管理当前使用的版本。

4. 初窥门径：wrk基础命令与参数详解

安装成功后，让我们先抛开复杂的脚本，用最基础的命令来感受一下wrk的威力。它的命令行参数设计得非常简洁。

一个最基础的压测命令如下：

wrk -t12 -c400 -d30s --latency http://localhost:8080/api/hello

让我们拆解每一个参数：

• -t12：指定使用12个线程。wrk会使用操作系统线程来执行压测。一个经验法则是，将其设置为测试机器CPU逻辑核心数（可通过nproc命令查看）或稍多一点，以充分压榨CPU。但并非越多越好，线程过多会增加上下文切换开销。我通常从与核心数相同开始测试。
• -c400：指定建立并保持400个HTTP连接。这是模拟的并发用户数。注意，这不是每秒请求数（RPS），这些连接会持续地发送请求。这个值需要根据你测试的服务类型来定。对于短连接服务，可以设置高一些；对于长连接，要结合系统资源。
• -d30s：指定压测持续时间为30秒。时间太短可能无法越过服务启动的“冷启动”阶段，数据不准确；时间太长则可能对线上或测试环境造成不必要负担。对于基准测试，30秒到2分钟是一个常见的范围。
• --latency：一个非常重要的标志。它告诉wrk在测试结束后，输出详细的延迟分布统计。这对于评估服务响应时间的稳定性至关重要，光看平均延迟是不够的。
• http://localhost:8080/api/hello：这就是我们要测试的目标URL。

执行完命令后，你会看到类似下面的输出：

Running 30s test @ http://localhost:8080/api/hello 12 threads and 400 connections Thread Stats Avg Stdev Max +/- Stdev Latency 250.12ms 46.11ms 1.02s 90.12% Req/Sec 133.05 25.69 250.00 75.25% Latency Distribution 50% 241.11ms 75% 267.89ms 90% 298.02ms 99% 401.33ms 47958 requests in 30.10s, 72.34MB read Requests/sec: 1593.33 Transfer/sec: 2.40MB

结果解读：

• Thread Stats：线程级别的统计。
  • Latency：延迟。Avg是平均延迟，Stdev是标准差（反映波动），Max是最长延迟，+/- Stdev表示有多少百分比的延迟数据落在平均值正负一个标准差范围内（此例90.12%的延迟在204.01ms~296.23ms之间）。
  • Req/Sec：每个线程每秒完成的请求数。这里的Avg是每个线程的平均值。
• Latency Distribution：延迟分布直方图。这是--latency参数的功劳。重点关注P99（99%）和P999（如果数据量大）延迟。它反映了最慢的那1%请求的体验。上例中99%的请求在401.33ms内返回，这个值比平均延迟高不少，说明存在一些慢请求。
• 汇总行：
  • 47958 requests in 30.10s：总请求数。
  • 72.34MB read：总数据传输量。
  • Requests/sec: 1593.33：这就是我们最关心的QPS（每秒请求数）。
  • Transfer/sec: 2.40MB：每秒传输的数据量。

其他常用参数：

• -H, --header：添加HTTP头。例如：-H "Authorization: Bearer xxxx" -H "Content-Type: application/json"。
• --timeout：设置请求超时时间，默认很长。如果测试的服务不稳定，可以设置为一个较小的值（如2s、5s），避免测试线程被挂死。
• -s, --script：指定Lua脚本路径，用于复杂测试。这是wrk的精华所在，我们下一章详解。

重要提示：第一次压测时，建议先用较小的-c（如10）和较短的-d（如5s）试跑一下，确保命令、网络、服务都是通的，再逐步增加压力。同时，务必在测试环境进行，避免对生产服务造成影响。

5. 登堂入室：使用Lua脚本实现高级压测场景

wrk的基础命令只能发起简单的GET请求。但真实的业务场景要复杂得多：POST JSON数据、传递动态参数、处理Cookie/Session、多个请求有顺序依赖等。这时，就必须请出wrk的“灵魂伴侣”——Lua脚本。

5.1 Lua脚本的基本结构与生命周期

wrk通过内嵌的LuaJIT引擎，在压测的不同阶段调用Lua脚本中特定的全局函数。一个完整的脚本通常包含以下几个部分：

-- 初始化阶段，每个线程只调用一次 function setup(thread) thread.addr = "..." -- 为线程设置变量，如不同的用户ID end -- 请求生成阶段，每次发起请求前调用，必须返回一个字符串（请求） function request() -- 动态生成请求路径、方法、头、体 return wrk.format(method, path, headers, body) end -- 响应处理阶段，每次收到响应后调用 function response(status, headers, body) -- 可以检查状态码、解析响应体、统计特定信息 if status ~= 200 then print("Unexpected status: ", status) end end -- 结束阶段，整个测试结束后调用一次 function done(summary, latency, requests) -- 可以在这里自定义输出报告，比如计算成功率、输出到文件等 local duration = summary.duration / 1000000 -- 转为秒 local errors = summary.errors.status + summary.errors.read + summary.errors.timeout local requests = summary.requests local valid_requests = requests - errors print(string.format("总请求数: %d", requests)) print(string.format("成功请求: %d (%.2f%%)", valid_requests, (valid_requests/requests)*100)) print(string.format("QPS: %.2f", valid_requests / duration)) end

生命周期详解：

1. setup(thread)：在压测线程启动后，运行前调用。你可以在这里为每个线程初始化一些私有数据，比如从文件读取一个用户ID列表，让不同线程使用不同的数据，避免所有线程行为完全一致。
2. request()：这是核心函数。wrk的每个工作线程会在其事件循环中不断调用此函数来获取下一个要发送的HTTP请求。你需要在这个函数里构造请求。wrk.format()是一个辅助函数，它能帮你把方法、路径、头、体组合成符合HTTP格式的请求字符串。
3. response(status, headers, body)：每当收到一个HTTP响应时，此函数被调用。你可以在这里进行响应验证、数据提取（如从JSON响应中取出token用于后续请求）或自定义统计。
4. done(summary, latency, requests)：整个压测运行结束后调用。你可以拿到全局的统计摘要、延迟对象和请求统计对象，生成比默认输出更丰富的自定义报告。

5.2 实战脚本示例：POST JSON与参数化

假设我们要测试一个用户登录接口：POST /api/login，请求体是JSON{"username": "userX", "password": "passX"}，并且我们希望用户名是参数化的（比如从user1到user100）。

我们可以编写如下脚本login_test.lua：

-- 初始化一个计数器，用于生成动态用户名 counter = 1 -- 定义请求方法、路径和固定的Header method = "POST" path = "/api/login" headers = {} headers["Content-Type"] = "application/json" -- 请求生成函数 function request() -- 构造JSON请求体，用户名动态变化 local body = string.format('{"username": "testuser%d", "password": "password123"}', counter) -- 更新计数器，简单循环1-100 counter = (counter % 100) + 1 -- 使用wrk.format生成完整请求 return wrk.format(method, path, headers, body) end -- 响应处理函数：检查登录是否成功 function response(status, headers, body) if status == 200 then -- 可以解析body，这里假设成功返回包含"token" if body and string.find(body, '"token"') then -- 登录成功，可以在这里做一些统计 -- 例如，将token存入线程变量，供后续接口使用（需要更复杂的setup和thread.data） else print("Login succeeded but no token found in body") end else -- 记录非200状态码的请求（在实际压测中，大量打印会影响性能，仅用于调试） -- print("Login failed with status: " .. status) end end

运行这个脚本：

wrk -t4 -c100 -d60s -s login_test.lua --latency http://your-api-server.com

5.3 进阶技巧：实现请求间依赖与思考时间

更复杂的场景，比如“先登录获取token，再用token查询用户信息”。这需要维护一个会话状态。我们可以利用setup函数为每个线程初始化一个“token”，并在request中根据当前“阶段”决定发送哪个请求。

-- 模拟用户先登录，后访问主页的场景 init_done = false -- 线程级别的标志，表示是否已初始化（登录） function setup(thread) -- 每个线程有自己的token变量 thread.token = nil end function request() local headers = {} headers["Content-Type"] = "application/json" if not init_done then -- 阶段1：发送登录请求 local login_body = '{"username": "test", "password": "test"}' return wrk.format("POST", "/api/login", headers, login_body) else -- 阶段2：使用获取到的token访问需要认证的接口 headers["Authorization"] = "Bearer " .. wrk.thread.token return wrk.format("GET", "/api/profile", headers, nil) end end function response(status, headers, body) if not init_done then -- 处理登录响应 if status == 200 then -- 假设响应体是 {"token": "eyJhbGciOi..."} local token = string.match(body, '"token"%s*:%s*"([^"]+)"') if token then wrk.thread.token = token init_done = true else print("Failed to extract token from login response") end end else -- 处理/profile接口的响应，可以做一些验证 if status ~= 200 then print("Profile request failed: " .. status) -- 如果token失效，可以重置init_done，重新登录（这里简化处理） end end end -- 可选：在done函数中统计登录成功率和后续接口成功率

关于思考时间：wrk本身设计是尽可能快地发送请求，以测量服务最大处理能力。如果要模拟用户真实操作间隔，可以在request()函数末尾添加wrk.thread:wait(interval_ms)。但请注意，这会使wrk变成“节奏发生器”，而不再是“压力发生器”，其QPS会受你设置的间隔限制，常用于模拟特定吞吐量的场景，而非极限压测。

6. 性能测试实战：设计、执行与结果分析

掌握了工具的使用，我们更需要一套方法论来指导如何进行一次有意义的性能测试。盲目地运行wrk并得到一个QPS数字是没有价值的。

6.1 测试环境与目标确立

黄金法则：测试环境必须尽可能贴近生产环境。硬件配置（CPU、内存、磁盘类型）、软件版本（操作系统、中间件、应用）、网络拓扑（是否经过负载均衡器）和数据集规模，任何一个因素的差异都可能导致测试结果失真。如果无法完全复制，至少要做到核心配置（如CPU架构和核心数、内存大小、数据库类型）一致。

在开始前，明确回答以下问题：

1. 测试目标是什么？是寻找单接口的极限QPS？还是验证在预期峰值流量下的响应时间是否达标（如P99 < 200ms）？或是比较两个优化方案A和B的性能差异？
2. 系统基准线是什么？如果是性能回归测试，当前的性能基准（Baseline）数据是多少？
3. 成功标准是什么？QPS达到多少？错误率低于多少（如<0.1%）？P95/P99延迟在多少毫秒以内？

例如，目标可以是：“在4核8G的测试机上，对/api/v1/orders接口进行30秒压测，在错误率低于0.5%的前提下，QPS达到1200，且P99延迟不超过500ms。”

6.2 设计压测策略与参数调优

1. 预热（Warm-up）：服务在刚启动时，JVM需要加载类、JIT编译热点代码，数据库连接池需要填充，缓存是冷的。直接压测得到的数据会很差。因此，正式压测前，应该先用一个较小的压力（如-c10 -d30s）跑1-2分钟，让服务“热”起来。
2. 阶梯加压（Ramp-up）：这是模拟真实流量增长、观察系统行为变化的有效方法。虽然wrk命令行不支持自动阶梯加压，但我们可以通过多次运行或编写Lua脚本来实现。例如：

   # 第一阶段：低并发，持续60秒 wrk -t4 -c50 -d60s --latency http://... # 等待10秒，观察系统指标是否恢复 sleep 10 # 第二阶段：中并发，持续60秒 wrk -t4 -c200 -d60s --latency http://... sleep 10 # 第三阶段：高并发，持续60秒 wrk -t4 -c500 -d60s --latency http://...

   通过分析每个阶段的QPS、延迟和错误率变化，可以找到性能拐点。
3. wrk参数调优：
   • 线程数（-t）：从等于CPU逻辑核心数开始测试。如果QPS上不去且CPU利用率不高，可以尝试增加到核心数的2倍。观察top命令中wrk进程的CPU使用率。
   • 连接数（-c）：这是最重要的参数。从小开始（如10），逐步倍增（20, 50, 100, 200, 500...），直到QPS曲线不再增长或错误率（连接错误、超时）显著上升。注意，连接数受测试机和服务端的文件描述符限制，可以提前用ulimit -n检查并调大。
   • 持续时间（-d）：基准测试至少30秒，稳定性测试可能需要5-10分钟甚至更长。时间太短，结果可能受GC、定时任务等偶然因素影响。
   • 超时时间（--timeout）：根据接口SLA设置。如果接口正常响应是100ms，可以设置为2s。这能防止个别慢请求阻塞测试线程。

6.3 结果分析与瓶颈定位

拿到wrk的输出后，如何解读？

1. 看整体QPS和错误率：这是最直观的指标。QPS是否达到预期？错误率（通过非200状态码和response函数中的判断来统计）是否在可接受范围内？
2. 分析延迟分布：重点关注P90, P95, P99。如果平均延迟很低但P99很高，说明服务存在“长尾”问题，少数请求体验极差。这可能是因为：
   • 资源竞争：如数据库锁、全局锁。
   • GC停顿：对于Java/Python等服务，长时间的GC会导致个别请求卡顿。
   • 外部依赖慢：某个请求调用的下游服务或数据库查询特别慢。
3. 结合系统监控：压测时，必须同时监控服务器资源！
   • CPU利用率：使用top或htop。如果CPU使用率接近100%，说明计算是瓶颈。用户态（us）高可能是应用代码问题，系统态（sy）高可能是系统调用频繁（如大量网络I/O）。
   • 内存：使用free -m。观察是否发生Swap，Swap会导致性能急剧下降。
   • 网络I/O：使用sar -n DEV 1或iftop。观察网络带宽是否打满。
   • 磁盘I/O：如果服务涉及大量读写，使用iostat -x 1。观察%util和await。
   • 应用/中间件监控：查看应用日志、数据库慢查询日志、连接池状态等。

常见瓶颈模式：

• QPS上不去，CPU利用率低：可能是连接数（-c）不够，未能给服务施加足够压力；也可能是服务内部有锁或阻塞操作（如同步I/O），导致无法充分利用CPU。
• QPS达到一个值后不再增长，延迟急剧上升：说明达到了服务的当前处理能力上限。需要结合监控判断是哪个资源（CPU、内存、数据库连接、网络带宽）成为瓶颈。
• 大量连接错误或超时：检查服务端和测试机的文件描述符限制、网络连接数限制，以及服务端是否有连接泄漏。

7. 避坑指南与高级技巧实录

在实际使用wrk的过程中，我踩过不少坑，也积累了一些让测试更高效、更准确的经验。

7.1 常见问题与排查

问题1：压测时出现 “Unable to connect to [host]” 或 “Connection refused”

• 原因：目标服务未启动，或网络不通（防火墙、安全组规则）。
• 排查：
  1. 在测试机上用curl或telnet手动测试目标端口是否能连通。
  2. 检查服务进程是否在运行：ps aux | grep [your-service]。
  3. 检查服务监听的IP和端口是否正确（netstat -tlnp）。
  4. 检查服务器防火墙（firewall-cmd/ufw）和云服务商的安全组规则，是否放行了测试机IP对目标端口的访问。

问题2：压测开始后，wrk的QPS很低，且测试机CPU/网络利用率也很低

• 原因：最常见的原因是连接数（-c）设置得太小。wrk的每个线程会处理多个连接，但如果总连接数少于线程数，线程可能闲置。
• 解决：逐步增加-c的值，观察QPS和资源利用率的变化。一个经验是，初始连接数可以设置为线程数的50-100倍。

问题3：测试中途出现大量 “Socket errors: connect timed out, read timed out”

• 原因：服务端处理不过来，请求堆积，导致wrk端的连接建立或读取超时。
• 排查：
  1. 首先降低压力（减小-c），看错误是否消失。如果消失，说明确实是服务端达到瓶颈。
  2. 检查服务端日志，看是否有大量错误（如数据库连接池耗尽、内存溢出）。
  3. 检查服务端和测试机的网络状况，是否存在丢包（ping，mtr）。
  4. 适当增加wrk的--timeout参数（如设置为10s），但这不是根本解决办法，只是让测试能完成，便于收集错误期的系统状态。

问题4：Lua脚本中动态变量导致所有请求都一样

• 原因：Lua脚本中的变量默认是“全局”的，所有线程共享。如果在request()函数外定义了一个计数器，所有线程会操作同一个计数器，导致数据混乱或达不到参数化效果。
• 解决：使用线程局部变量。在setup(thread)函数中初始化：thread.my_counter = 1。在request()函数中通过wrk.thread.my_counter来访问和修改。

7.2 高级技巧与最佳实践

1. 使用多个wrk实例进行分布式压测：单台测试机的网络带宽或文件描述符可能成为瓶颈。要产生更大的压力，可以从多台机器同时运行wrk。你需要确保它们的时间基本同步，并手动汇总结果。更专业的做法是使用像wrk2（一个wrk的变种，专注于产生恒定吞吐量）或容器化编排一批wrk实例。
2. 结果输出与自动化：wrk的默认输出是给人看的。如果想集成到CI/CD流水线，需要解析其输出。可以结合--latency输出和done()函数中的summary、latency对象，将关键指标（QPS, P99, 错误率）以JSON格式打印出来，然后用jq等工具解析。例如在done()函数中：

   function done(summary, latency, requests) local result = { duration = summary.duration / 1000000, requests = summary.requests, errors = summary.errors.status + summary.errors.read + summary.errors.timeout, bytes = summary.bytes, latency_p99 = latency:percentile(99.0) / 1000 -- 转为毫秒 } print(require("cjson").encode(result)) -- 需要确保cjson库可用 end

3. 保持测试的公平性与可重复性：
   • 每次测试前，重启服务，清除缓存，确保起点一致。
   • 记录完整的测试环境信息（硬件配置、软件版本、内核参数、wrk参数、脚本内容）。
   • 多次运行取平均值，避免单次运行的偶然性。
4. 理解“开箱即用”的局限：wrk默认使用HTTP/1.1和Keep-Alive。如果你要测试HTTP/2或故意测试短连接（每次请求新建连接），需要调整脚本或使用其他工具（如h2load）。对于WebSocket等长连接协议，wrk也不直接支持，需要寻找专用工具或自己用其他语言编写测试客户端。

性能测试不是一个运行完命令就结束的动作，而是一个“施加压力 -> 观察现象 -> 定位瓶颈 -> 优化系统 -> 再次验证”的循环。wrk是这个循环中非常锋利的一把探测刀，它能快速帮你找到系统的“天花板”和“脆弱点”。但解读数据、定位根因，更需要你对整个系统架构的深入理解。把wrk的数据，和APM（应用性能监控）、基础设施监控、日志分析结合起来，你才能真正洞悉系统在压力下的行为，做出有效的优化。