发表于 | 分类于 | 0 | 阅读次数 273

常见轻量型HTTP基础压测工具

在项目正式上线之前，我们通常需要通过压测来评估当前系统能够支撑的请求量、排查可能存在的隐藏bug，同时了解了程序的实际处理能力能够帮我们更好的匹配项目的实际需求，节约资源成本。

压测相关术语：

  • 响应时间(RT) ：指系统对请求作出响应的时间.
  • 吞吐量(Throughput) ：指系统在单位时间内处理请求的数量
  • QPS每秒查询率(Query Per Second) ：“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
  • TPS(TransactionPerSecond)：每秒钟系统能够处理的交易或事务的数量
  • 并发连接数：某个时刻服务器所接受的请求总数

ab

ab全称Apache Bench，是 Apache 提供的一款测试工具，具有简单易上手的特点，在测试 Web 服务时非常实用。

命令格式：

ab [options] [http://]hostname[:port]/path

常用参数如下：

-n requests 总请求数（最小默认为 1）
-c concurrency 并发次数（最小默认为 1 且不能大于总请求次数，例如：10 个请求，10 个并发，实际就是 1 人请求 1 次）
-t timelimit 测试所进行的最大秒数, 可以当做请求的超时时间
-p postfile 包含了需要POST的数据的文件（-p 和-T 参数要配合使用）
-T content-type POST数据所使用的Content-type头信息

更多参数请查看官方文档。

例如测试某个GET请求接口：

# 总请求10W，100个并发
ab -n 100000 -c 100 "http://kongtest.com"

测试POST请求接口：

ab -n 100000 -c 100 -p post.json -T "application/json" "http://kongtest.com

输出结果如下：

111

以上输出中，有几项性能指标可以提供给我们参考使用：

  • Requests per second：吞吐率，指某个并发用户数下单位时间内处理的请求数；
  • Time per request：上面的是用户平均请求等待时间，指处理完成所有请求数所花费的时间/（总请求数/并发用户数）；
  • Time per request：下面的是服务器平均请求处理时间，指处理完成所有请求数所花费的时间/总请求数；
  • Percentage of the requests served within a certain time：每秒请求时间分布情况，指在整个请求中，每个请求的时间长度的分布情况，例如有 50%的请求响应在 11ms 内，66%的请求响应在 12ms 内，说明有 10%的请求在 11ms~12ms 之间。

wrk

wrk 是一款开源的HTTP性能测试工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。它和上面提到的ab同属于HTTP性能测试工具，它比ab功能更加强大，可以通过编写lua脚本来支持更加复杂的测试场景。

命令格式：

$ wrk [options] [http://]hostname[:port]/path

常用参数如下：

-c, --connections: 要保持打开的HTTP连接的总数，每个线程处理数N =连接/线程
-d, --duration:    测试持续时间, 如 2s, 2m, 2h
-t, --threads:     测试线程总数
-s, --script:      指定加载lua测试扩展脚本
-H, --header:      添加请求头信息, 如"User-Agent: wrk"
--latency:     打印延迟直方图信息
--timeout:     如果在此时间内没有收到响应，则记录超时.

基础使用

wrk -t12 -c100 -d30s --latency http://127.0.0.1:8080/index.html

如上指令描述了采用12个线程，100个链接，针对http://127.0.0.1:8080/index.html 接口服务，持续压测30s。wrk本身不是依赖线程数来模拟并发数的所以线程数量设置在核心数左右最好，线程数多了测试系统消耗大，可能带来反效果。亲测核心数一致的线程数和两倍核心数的线程数，前者压出的QPS更高。结果如下：

Running 30s test @  http://127.0.0.1:8080/index.html（运行30s测试）
  12 threads and 100 connections（12个线程100个连接）
    Thread Stats        Avg(均值)      Stdev(标准差值)     Max(最大值)   +/- Stdev(正负标准差值)
    Latency(延迟)         1.39ms        668.10us           23.95ms       90.34%
    Req/Sec(每秒请求数)    5.44k          545.23             10.27k        76.47%
  Latency Distribution(延迟直方图)
     50%    1.32ms (50%请求延迟在1.32ms内)
     75%    1.49ms (75%请求延迟在1.49ms内)
     90%    1.72ms (90%请求延迟在1.72ms内)
     99%    4.77ms (99%请求延迟在4.77ms内)
  1952790 requests in 30.08s, 271.90MB read (共1952790次请求，用时30s，传输了271.9M数据)
Requests/sec(每秒请求数):  64930.12
Transfer/sec(每秒传输数据):      9.04MB

wrk的结果相比ab测试结果来说，多了一个延时直方图，有了这个直方图，我们可以更清晰的看到延迟的分布情况。

wrk还可以通过lua脚本来进行复制测试