几种网站压力测试工具调研与使用

在项目上线之前，都需要做压力测试，目的是看下我们的网站能抗住多少的压力，能承担多少并发，如果不做压力测试，一旦出现大访问量时，我们的网站会挂掉。因此，我们对现有较流行的几种网络压力测试工具进行了简单调研并尝试部署使用。

1、 在线网站
有一些网站提供了在线压力测试功能，例如腾讯提供的 wetest 压测大师, Nice tool, load impact, Post Json, PostMan等。我们也尝试使用了其中的一些，就使用上来说比较简单，但是在一些特殊极端情况下不是十分理想。

1.1. 优势

经过我们的尝试，我们认为在线网站主要有以下优势：

a、配置简单 使用在线网站不需要自己在本地搭载环境，编写代码，并有一个较完善的UI界面。

b、功能多 以wetest为例，可以提供监控核心性能指标如TPS、响应时间CPU、内存、磁盘IO、网卡负载、压力机性能监测等（需求腾讯云）

c、结果展示直观 上述大部分网站都可以直接以图表的形式显示结果，直观并且可以直接在展示中使用

1.2. 缺陷

a、并发限制 在线网站往往有最大并发限制，例如上述网站未登录的情况下都限制最大并发10~50。wetest，nicetool可以通过注册的方式增加并发限制，然而注册过程较繁琐，需要提供证明材料。

b、可定制化较低 很容易理解，在线网站测试的可定制化程度一定比自己写代码要低。

c、链接速度问题 在做实际测试是，我们当然希望测试的是服务器的性能而不是网络质量。因此，使用网站的结果可能会没有直接在服务器上部署测试来的准确。

1.3. 测试结果样例

这里我们以nicetool为例，执行50并发，100请求的测试，结果如下：

Summary:
  Total:    1.3244 secs
  Slowest:  0.4565 secs
  Fastest:  0.1701 secs
  Average:  0.2889 secs
  Requests/sec: 151.0075
  

Response time histogram:
  0.170 [1]     |
  0.199 [88]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.227 [3]     |■
  0.256 [1]     |
  0.285 [0]     |
  0.313 [0]     |
  0.342 [36]    |■■■■■■■■■■■■■■■■
  0.371 [21]    |■■■■■■■■■■
  0.399 [0]     |
  0.428 [14]    |■■■■■■
  0.456 [36]    |■■■■■■■■■■■■■■■■


Latency distribution:
  10% in 0.1722 secs
  25% in 0.1751 secs
  50% in 0.3367 secs
  75% in 0.4204 secs
  90% in 0.4365 secs
  95% in 0.4415 secs
  99% in 0.4536 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0196 secs, 0.1701 secs, 0.4565 secs
  DNS-lookup:   0.0031 secs, 0.0000 secs, 0.0131 secs
  req write:    0.0001 secs, 0.0000 secs, 0.0027 secs
  resp wait:    0.2689 secs, 0.1699 secs, 0.3761 secs
  resp read:    0.0003 secs, 0.0001 secs, 0.0049 secs

Status code distribution:
  [200] 200 responses

2、测试工具
除了在线网站，我们也调研并使用了一些其它工具，包括 ab, pylot, siege等。下面做一下简单介绍，基本按照推荐顺序。

2.1. ab

ab 的全称是apache bench，是由Apache提供的一款简单高效的测试工具，支持windows和linux等。

2.1.1. 使用方法

首先需要下载Apache，对于windows，cmd进入安装目录的BIN文件夹下就可以执行ab了。对于Linux，一般可以通过安装Apache服务解决。

ab包括以下参数：

-n 执行的请求数量
-c 并发请求个数
-t 测试所进行的最大秒数
-p 包含了需要POST的数据的文件
-T POST数据所使用的Content-type头信息
-k 启用HTTP KeepAlive功能，即在一个HTTP会话中执行多个请求，默认时，不启用KeepAlive功能

一个简单的例子是

ab -n 100 -c 100 http://www.baidu.com/

2.1.2. 测试结果

我们使用

ab -n 100 -c 100 https://ratemycourse.tk/

进行了测试，测试结果如下:

Server Software:        cloudflare
Server Hostname:        ratemycourse.tk
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-CHACHA20-POLY1305,256,256
TLS Server Name:        ratemycourse.tk

Document Path:          /
Document Length:        6856 bytes

Concurrency Level:      100
Time taken for tests:   3.153 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      732100 bytes
HTML transferred:       685600 bytes
Requests per second:    31.72 [#/sec] (mean)
Time per request:       3153.013 [ms] (mean)
Time per request:       31.530 [ms] (mean, across all concurrent requests)
Transfer rate:          226.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      489  632 130.8    611    1232
Processing:   167  412 359.8    347    2159
Waiting:      164  223  86.2    193     817
Total:        695 1044 405.5    927    3133

Percentage of the requests served within a certain time (ms)
  50%    927
  66%   1029
  75%   1078
  80%   1154
  90%   1586
  95%   1895
  98%   2818
  99%   3133
 100%   3133 (longest request)

2.1.3. 优势与缺陷

ab提供的测试结果内容较多，十分完整，包括连接成功数，响应时间等多种内容并做了简单分析，足够使用。主要缺点是不能监控，没有图形化结果。ab好像是单核的，因此高并发时可能造成测试瓶颈。另外我服务器上已经使用了Nginx作为webserver，再安装Apache等还需要处理一些冲突问题。

2.2. siege

siege 是一个十分常用的开源的web服务压力测试工具，可以模拟数千并发的请求，并给出一个简单的统计。siege的安装使用非常简单，下以Ubuntu/Debian为例。

2.2.1. 安装siege

siege可以通过编译源码与apt两种方式安装，需要注意的是官网链接不是很稳定，虽然压缩包大小仅有511K但是依然需要代理访问，因此更推荐使用apt安装。

源码安装的方式如下：

wget http://download.joedog.org/siege/siege-latest.tar.gz
tar -zxvf siege-latest.tar.gz
cd siege-4.0.4/
./configure
make
make install

sudo apt install siege

2.2.2. siege简单教程

我们摘录了这篇文章中介绍用法的部分。

-C,或–config 在屏幕上打印显示出当前的配置,配置是包括在他的配置文件HOME/.siegerc中,可以编辑里面的参数,这样每次siege都会按照它运行.−v运行时能看到详细的运行信息−cn,或–concurrent=n指定并发的用户个数，−c200指定并发数200。模拟有n个用户在同时访问,n不要设得太大,因为越大,siege消耗本地机器的资源越多−i,–internet随机访问urls.txt中的url列表项,以此模拟真实的访问情况(随机性),当urls.txt存在是有效。默认为urls.txt列表从上到下来压。−dn,–delay=nhit每个url之间的延迟,在0−n之间−rn,–reps=n重复运行测试n次,不能与−t同时存在−tn,–time=n持续时间。即测试持续时间。默认是分钟。例:−t10S,(10秒)−t5M,(5分钟)−t1H,(1小时)−l运行结束,将统计数据保存到日志文件中siege.log,一般位于/usr/local/var/siege.log中,也可在.siegerc中自定义−RSIEGERC,–rc=SIEGERC指定用特定的siege配置文件来运行,默认的为HOME/.siegerc中,可以编辑里面的参数,这样每次siege都会按照它运行.−v运行时能看到详细的运行信息−cn,或–concurrent=n指定并发的用户个数，−c200指定并发数200。模拟有n个用户在同时访问,n不要设得太大,因为越大,siege消耗本地机器的资源越多−i,–internet随机访问urls.txt中的url列表项,以此模拟真实的访问情况(随机性),当urls.txt存在是有效。默认为urls.txt列表从上到下来压。−dn,–delay=nhit每个url之间的延迟,在0−n之间−rn,–reps=n重复运行测试n次,不能与−t同时存在−tn,–time=n持续时间。即测试持续时间。默认是分钟。例:−t10S,(10秒)−t5M,(5分钟)−t1H,(1小时)−l运行结束,将统计数据保存到日志文件中siege.log,一般位于/usr/local/var/siege.log中,也可在.siegerc中自定义−RSIEGERC,–rc=SIEGERC指定用特定的siege配置文件来运行,默认的为HOME/.siegerc
-f FILE, –file=FILE 指定用特定的urls文件运行siege ,默认为urls.txt,位于siege 安装目录下的etc/urls.txt
-u URL,–url=URL 测试指定的一个URL,对它进行”siege “,此选项会忽略有关urls文件的设定
-b 进行压力测试，不进行延时。
-A, --user-agent=“text” 设置请求的User-Agent

使用以上命令基本可以满足大部分测试需求了。以我们的测试为例，我们考察了1000并发下的网站工作情况，使用了如下命令：

siege -c 100  https://ratemycourse.tk -i -b

2.2.3. 测试结果

简单测试结果如下：

Lifting the server siege...
Transactions:                    100 hits
Availability:                 100.00 %
Elapsed time:                   2.30 secs
Data transferred:               0.23 MB
Response time:                  1.29 secs
Transaction rate:              45.65 trans/sec
Throughput:                     0.10 MB/sec
Concurrency:                   58.68
Successful transactions:         100
Failed transactions:               0
Longest transaction:            1.53
Shortest transaction:           1.04

2.2.4. 优势与缺点

siege安装方便，比起ab，不需要解决与nginx可能的冲突的问题。siege的测试速度直观上比ab更快。siege提供的信息要略少一些，不过对于简单分析依然足够。

另外siege有一个小坑：siege的最大并发链接默认值是255，需要手动到配置文件中修改。siege在WSL和部分macOS上启动会失败，建议使用虚拟机或完整的Linux环境。

2.3. pylot

pylot是一个python写的测试工具，支持命令行与图形界面，支持生成图表，配置简单易用。其实pylot是我最早尝试的工具，因为简介博客说它基于python，又可以画图。

然而简介总是美好的，现实总是残酷的。简单来说，就目前请不要再试图使用或推荐pylot了。

首先是官网进不去。我们在博客的介绍里找到了所谓的官网：www.pylot.org，然而实际上这个网站现在是emmm，在线发牌。
幸运的是，我们还有web archive这个老朋友。emmm，然而看上去最后更新的版本2009/07/06的。另外它好像只支持python2，我也不知道有没有人在继续维护。

就结论来说，我好像浪费了一小时试图搞定这个玩意。

2.4. http_load

程序非常小，解压后也不到100K
http_load以并行复用的方式运行，用以测试web服务器的吞吐量与负载。
但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。
还可以测试HTTPS类的网站请求。
下载地址：http_load-12mar2006.tar.gz

安装很简单：

#tar zxvf http_load-12mar2006.tar.gz
#cd http_load-12mar2006
#make && make install

基本用法：

http_load  -p 并发访问进程数  -s 访问时间  需要访问的URL文件

参数其实可以自由组合，参数之间的选择并没有什么限制。
比如你写成http_load -parallel 5 -seconds 300 urllist.txt也是可以的。
我们把参数给大家简单说明一下。
-parallel 简写-p ：含义是并发的用户进程数。
-fetches 简写-f ：含义是总计的访问次数
-rate 简写-p ：含义是每秒的访问频率
-seconds 简写-s ：含义是总计的访问时间

准备URL文件：urllist.txt，文件格式是每行一个URL，URL最好超过50－100个测试效果比较好。

文件格式如下：

http://www.qixing318.com/
http://www.qixing318.com/blog/
http://www.qixing318.com/signin/
http://www.qixing318.com/signup/
http://www.qixing318.com/article/a-quick-look-at-the-redis-source-code.html
http://www.qixing318.com/article/how-the-browser-end-encryption.html
http://www.qixing318.com/article/jquery-form-validation-plug-in-validate.js-the-basic-usage.html
http://www.qixing318.com/article/use-flash-plugin-swfupload-head-is-upload-the-screenshot-in-two-ways.html
http://www.qixing318.com/article/should-make-your-site-using-html5.html
http://www.qixing318.com/article/simple-to-understand-linux-memory-allocation-mechanism.html
http://www.qixing318.com/article/organize-the-sphinx-api-based-on-php.html
http://www.qixing318.com/article/jquery-1-9-removed-browser-method-alternatives.html
http://www.qixing318.com/article/the-installation-of-fedora-under-chinese-search-sphinx-configuration.html
http://www.qixing318.com/article/schema-org-tag-was-used-to-optimize-web-pages.html
http://www.qixing318.com/article/jquery-reference-manual-tutorials-and-tools.html
http://www.qixing318.com/article/falling-in-love-with-bike-30-reasons.html
http://www.qixing318.com/article/online-test-tools-browserstack-cross-browser-compatibility.html
http://www.qixing318.com/article/talk-about-javascript-image-preloading-technology.html
http://www.qixing318.com/article/brokeback-mountain.html
http://www.qixing318.com/article/sql-index-caused-performance-issues.html
http://www.qixing318.com/article/use-python-scapy-reporter.html
http://www.qixing318.com/article/a-python-web-attack-script.html

例如：

http_load -p 30 -s 60  urllist.txt

参数了解了，我们运行一条命令来看看它的返回结果分析：

1、294 fetches, 30 max parallel, 3.83835e+06 bytes, in 60.0026 seconds
说明在上面的测试中运行了294个请求，最大的并发进程数是30，总计传输的数据是3.83835e+06bytes，运行的时间是60.0026秒
2、13055.6 mean bytes/connection
说明每一连接平均传输的数据量3.83835e+06/294=13055.6
3、4.89979 fetches/sec, 63969.7 bytes/sec
说明每秒的响应请求为4.89979，每秒传递的数据为63969.7 bytes/sec
4、msecs/connect: 312.009 mean, 1319.57 max, 209.994 min
说明每连接的平均响应时间是312.009 msecs，最大的响应时间1319.57 msecs，最小的响应时间209.994 msecs
5、msecs/first-response: 1191.01 mean, 10212.4 max, 220.78 min
6、HTTP response codes:
code 200 – 127
code 502 – 166
说明打开响应页面的类型
如果403的类型过多，那可能要注意是否系统遇到了瓶颈。
特殊说明：
测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项，即服务器每秒能够响应的查询次数。
用这个指标来衡量性能。似乎比 apache的ab准确率要高一些，也更有说服力一些。
Qpt-每秒响应用户数和response time，每连接响应用户时间。
测试的结果主要也是看这两个值。
当然仅有这两个指标并不能完成对性能的分析，我们还需要对服务器的cpu、men进行分析，才能得出结论。

2.5. webbench

webbench是Linux下的一个网站压力测试工具，最多可以模拟3万个并发连接去测试网站的负载能力。
下载地址可以到google搜，我这里给出一个
下载地址：http://soft.vpser.net/test/webbench/webbench-1.5.tar.gz
这个程序更小，解压后不到50K，呵呵
安装非常简单

#tar zxvf webbench-1.5.tar.gz
#cd webbench-1.5
#make && make install

会在当前目录生成webbench可执行文件，直接可以使用了
用法：webbench -c 并发数 -t 运行测试时间 URL

例如：

#webbench -c 1000 -t 130 http://hui.zhifou123.com

2.6. 简单总结

总的来说，这些测试工具比起网站可以自己部署，可以自己定制功能。直接部署到服务器上或者与服务器有较高连接速率的服务器上（例如同一局域网）可以最大限度避免网络质量导致的误差。相较于在线测试网站，我们也可以自定义更大的连接数，测试更高的并发。

3、造轮子自己写脚本
除了使用上面的工具之外，我们还可以使用自己写的一些其他脚本实现更多功能。利用python的request库，简单的就可以模拟一个请求。自己写的脚本往往可以实现更多特殊的功能，但是他们同样也会面临一些问题，例如鲁棒性，异常处理完整性，测试的公平准确性等问题。例如，下面的测试代码模拟了连续25秒，每秒请求200次的压力测试。

import requests
import threading
import time

class thread1(threading.Thread):
    count200=0
    count502=0
    count504=0
    count500=0
    countelse=0
    def __init__(self, threadID, name):
        threading.Thread.__init__(self)
        self.threadID = threadID
        self.name = name
    def run(self):
        time.sleep(50)
        code = requests.get(YOUR_WEB_SITE).status_code
        if int(code)==200:
            thread1.count200+=1
        elif int(code)==502:
            thread1.count502+=1
        elif int(code)==504:
            thread1.count504+=1
        elif int(code)==500:
            thread1.count500+=1
        else:
            thread1.countelse+=1

if __name__=="__main__":
    threads=[]
    for i in range(5000):
        thread=thread1(i, "Thread-{}".format(i))
        threads.append(thread)
    for i in threads:
        i.start()
        time.sleep(0.005)
    for i in threads:
        i.join()
    print(thread1.count200,thread1.count502,thread1.count504,thread1.count500,thread1.countelse)

4、最终推荐
在实际使用中，我们使用了siege辅以自己编写的脚本进行测试。实际上，我们认为 ab、siege、http_load 和 webbench 都是十分优秀的解决方案。