服务器压力测试工具
并发压力测试时用来测试一个网站的并发能力的,但根据实际需求往往我们不该过早优化
这里就大致根据理论最大QPS,给网站做几个分类:
- 50QPS以下——小网站
没什么好说的,简单的小网站而已,就如同本站这样,你可以用最简单的方法快速搭建,短期没有太多的技术瓶颈,只要服务器不要太烂就好。
- 50~100QPS——DB极限型
大部分的关系型数据库的每次请求大多都能控制在0.01秒左右,即便你的网站每页面只有一次DB请求,那么页面请求无法保证在1秒钟内完成100个请求,这个阶段要考虑做Cache或者多DB负载。无论那种方案,网站重构是不可避免的。
- 300~800QPS——带宽极限型
目前服务器大多用了IDC提供的“百兆带宽”,这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte,在这个并发条件下,百兆带宽已经吃完。首要考虑是CDN加速/异地缓存,多机负载等技术。
- 500~1000QPS——内网带宽极限+Memcache极限型
由于Key/value的特性,每个页面对memcache的请求远大于直接对DB的请求,Memcache的悲观并发数在2w左右,看似很高,但事实上大多数情况下,首先是有可能在次之前内网的带宽就已经吃光,接着是在8K QPS左右的情况下,Memcache已经表现出了不稳定,如果代码上没有足够的优化,可能直接将压力转嫁到了DB层上,这就最终导致整个系统在达到某个阀值之上,性能迅速下滑。
- 1000~2000QPS——FORK/SELECT,锁模式极限型
好吧,一句话:线程模型决定吞吐量。不管你系统中最常见的锁是什么锁,这个级别下,文件系统访问锁都成为了灾难。这就要求系统中不能存在中央节点,所有的数据都必须分布存储,数据需要分布处理。总之,关键词:分布
- 2000QPS以上——C10K极限
尽管现在很多应用已经实现了C25K,但短板理论告诉我们,决定网站整体并发的永远是最低效的那个环节。我承认我生涯中从未遇到过2000QPS以上,甚至1.5K以上的网站,希望有此经验的哥们可以一起交流下
ab
apache的优秀遗产之一,用法非常简单
ab -n1000 -c10 http://...
- -n 表示并发数
- -c 一次产生的请求个数(并发数)。默认是一次一个
- -p 包含了需要POST的数据的文件,文件格式如“p1=1&p2=2”.使用方法是 -p 111.txt 。 (配合-T)
- -T POST数据所使用的Content-type头信息,如 -T “application/x-www-form-urlencoded” 。 (配合-p)
- -w 以HTML表的格式输出结果。默认时,它是白色背景的两列宽度的一张表。
-
-C -C cookie-name=value 对请求附加一个Cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复,用逗号分割。 提示:可以借助session实现原理传递 JSESSIONID参数, 实现保持会话的功能,如
-C ” c1=1234,c2=2,c3=3, JSESSIONID=FF056CD16DA9D71CB131C1D56F0319F8″ 。
- -P proxy-auth-username:password 对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开,并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码),此字符串都会被发送。
以百度为例:
ab -n1000 -c100 https://www.baidu.com/
可以看到一串结果:
/**
* 版权声明
*/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
/**
* 过程演示
*/
Benchmarking www.baidu.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: bfe/1.0.8.14 //服务器软件
Server Hostname: www.baidu.com //服务器名
Server Port: 443 //端口
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128 //SSl/TLS协议号
Document Path: / //静态文件目录
Document Length: 227 bytes //页面大小
Concurrency Level: 100 //并发等级
Time taken for tests: 12.924 seconds //测试耗时
Complete requests: 1000 //完成的请求数
Failed requests: 0 //失败的请求数
Total transferred: 1082274 bytes //一共传输的信息量
HTML transferred: 227000 bytes //html文件的信息量
Requests per second: 77.37 [#/sec] (mean) //每秒平均请求数
Time per request: 1292.420 [ms] (mean) //每个请求的凭据耗时
Time per request: 12.924 [ms] (mean, across all concurrent requests) //交叉并行的每个请求平均耗时
Transfer rate: 81.78 [Kbytes/sec] received //传输比率
/**
* 连接耗时统计
*/
Connection Times (ms)
min mean[+/-sd] median max
Connect: 367 885 915.3 568 8937
Processing: 99 230 119.7 202 963
Waiting: 99 197 91.8 176 938
Total: 537 1114 913.7 792 9056
/**
* 各个时间百分比节点的请求处理量
*/
Percentage of the requests served within a certain time (ms)
50% 792 //50%的请求在792秒内完成
66% 920
75% 1146
80% 1358
90% 1858
95% 2512
98% 4295
99% 6550
100% 9056 (longest request)
Siege
安装
直接brew安装
设置:
siege.config
生成.siegerc
文件,之后打开,修改其中的
verbose=false
concurrent=20
delay=1
internet=true
benchmark=true
limit = 200000
这货的报告相对简洁
使用:
-
50个用户 重复100次 发送GET参数
siege -c 50 -r 100 https://www.abc.com/a.php?name=zhangsan
-
50个用户 重复100次 发送POST参数 (注意引号)
siege -c 50 -r 100 "https://www.abc.com/a.php POST name=zhangsan"
-
50个用户 重复100次 发送POST参数(从文件中读取)
siege -c 50 -r 100 "https://www.abc.com/a.php POST < /root/ab_test/post.xml"
-
1000并发 持续5秒测试
siege -c 1000 -t 5s URL
t参数需要带单位,ß秒(如10S),分钟(10M),小时(10H)
报告说明
** SIEGE 3.1.3
** Preparing 2000 concurrent users for battle.
The server is now under siege.. done.
Transactions: 2000 hits //一共2000次处理
Availability: 100.00 % //成功率
Elapsed time: 110.71 secs //总耗时
Data transferred: 0.02 MB //总数据传输量
Response time: 0.01 secs //响应时间,可以反映网络连接熟读
Transaction rate: 18.07 trans/sec //每秒事务处理量,可以反映后端处理速度
Throughput: 0.00 MB/sec //吞吐量平均每秒传送数据
Concurrency: 0.10 //最高并发数
Successful transactions: 2000 //成功的事务数
Failed transactions: 0 //失败的事务数
Longest transaction: 0.06 //最长事务耗时,单位为s
Shortest transaction: 0.00 //最短事务耗时,单位为s
Boom
Boom是一个简单的压测工具,使用gevent,它的能力有限但使用比上的都方便,有python环境就可以使用,而且它可以作为模块,也就是说测试的方式可以通过python脚本定义.具体用法可以看官方文档.