简单易懂。green:一般指响应时间

95线：P95。平均100%的请求中95%已经响应的时间

99线：P99。平均100%的请求中99%已经响应的时间

平均响应时间：所有请求的平均响应时间

最大响应时间：所有请求中最大的响应时间

1.2 吞吐量

简单易懂。green:即每秒处理的请求数量

对于查询搜索类的系统使用每秒处理的请求数（QPS）来衡量吞吐能力。

一般对于交易类的系统使用每秒处理的事务数（TPS）来衡量吞吐能力。

TPS：每秒处理的事务数（比如每秒处理的订单数）

QPS：每秒处理的请求数

也叫做设计容量，可以理解为硬件配置(内存，cpu什么的)，成本约束

wrk 是一款针对 Http 协议的基准测试开源工具，它能够在单机多核 CPU 的条件下，使用red:系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。

wrk 目前仅支持单机压测，后续也不太可能支持多机器对目标机压测。

因为它本身的定位，并不是用来取代 JMeter, LoadRunner 等专业的测试工具，wrk 提供的功能，对后端开发人员来说，应付日常接口性能验证还是比较友好的。

wrk 只能被安装在类 Unix 系统上，所以我们需要一个 Linux 或者 MacOS 环境。Windows 10 安装需要开启自带的 Ubuntu 子系统。

3、使用 wrk

使用方法: wrk <选项> <被测HTTP服务的URL>

Options:

-c, --connections <N> 跟服务器建立并保持的TCP连接数量  

-d, --duration <T> 压测时间           

-t, --threads <N> 使用多少个线程进行压测   

-s, --script <S> 指定Lua脚本路径       

-H, --header <H> 为每一个HTTP请求添加HTTP头      

    --latency 在压测结束后，打印延迟统计信息   

    --timeout <T> 超时时间     

-v, --version 打印正在使用的wrk的详细版本信息

代表数字参数，支持国际单位 (1k, 1M, 1G)

代表时间参数，支持时间单位 (2s, 2m, 2h)

简单进行一次压测，用10个线程，200个连接，对百度进行30s的压测。

以下是对压测结果

wrk -t 10 -c 200 -d 30s --latency http://www.baidu.com



# 30s内测试百度的结果如下：

Running 30s test @ http://www.baidu.comm/



# 用12个线程 400个连接测试

12 threads and 400 connections



  Latency Distribution

  # 响应时间-延迟分布明细

  # 有50%的请求执行时间是在64.42ms内完成

  50% 64.42ms

  

  # 30秒内功处理了 149798 个请求，

  读取了 241.85MB 的数据

  149798 requests in 30.09s, 241.85MB read



 # QPS 4977.65, 即平均每秒处理请求数为4977.65 

 可以参考吞吐量。

 Requests/sec: 4977.65



# 平均每秒读取 8.04M 的数据

Transfer/sec: 8.04MB

3.2 编写压测脚本

首先需要准备一个 lua 文件，比如名为 test-postapi.lua ，写入如下内容。

### 请求方式

wrk.method = "POST"



### 设置 请求类型

wrk.headers["Content-Type"] = "application/json"



### POST 请求参数

wrk.body = '{"username": "13999999999","username": "13999999999"}'

这个文件内容自己写，写好接口内容后保存。

以下是模拟6个线程，600个连接，在60s内，间隔6s 执行 test-postapi.lua 脚本的请求。

# 进入wrk执行文件目录

# --script 参数的值为脚本名

# --latency 参数的值为接口地址

./wrk -t6 -c600 -d60s --script=test-postapi.lua --latency http://api.xxxdev.com/enterprise/user/login

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！