Apache ab性能测试结果分析
一直以来我都是用Loadrunner去做性能测试。Loadrunner实际上是一个很重的性能测试工具。他的功能很全面，是一把很好的牛刀。
如果我们只是需要对一个页面做简单的性能测试，使用Loadruner这把牛刀就不是一个很好的选择了。
所以就找了把小刀－－ab来试试。这把小刀真的是轻巧又锋利，在这里就记录一下对ab测试过程中的一些自己的理解，供大家参考。
我们就拿百度首页来祭刀吧。首先你得有一把刀，也就是安装好Apache，网上教程一大堆就不复述了，本文使用MacBook自带的ab命令进行测试。
测试场景：模拟10个用户，对百度首页发起总共100次请求。
测试命令： ab -n 100 -c 10 https://www.baidu.com/index.html
本文主要针对ab的测试报告进行解析，有关ab的使用方法改天再新开贴交流。
测试报告：
下面来逐行解释我的理解，以下注释部分有查阅网上资料，但所写内容均为自己理解之后手打内容，希望加入自己的理解之后能让读者更容易理解。
bogon:~ tang$ ab -n 100 -c 10 https://www.baidu.com/index.html
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/
//以上为apache的版本信息，与本次测试无关
Benchmarking www.baidu.com (be patient).....done
//以上内容显示测试完成度，本次测试发起请求数量较少，完成较快，无中间过程显示。在请求数量很多时会分行显示当前完成数量。
Server Software: bfe/1.0.8.14 //被测试的服务器所用的软件信息，这里使用的是百度自己开发的反向代理Baidu Front End,类似nginx。
Server Hostname: www.baidu.com //被测主机名
Server Port: 443 //被测主机的服务端口号，一般http请求的默认端口号是80，https默认使用443端口
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128 //加密协议
Document Path: /index.html //请求的具体文件
Document Length: 227 bytes //请求的文件index.html大小
Concurrency Level: 10 //并发级别，也就是并发数，请求中－c参数指定的数量
Time taken for tests: 1.093 seconds //本次测试总共花费的时间
Complete requests: 100 //本次测试总共发起的请求数量
Failed requests: 0 //失败的请求数量。因网络原因或服务器性能原因，发起的请求并不一定全部成功，通过该数值和Complete requests相除可以计算请求的失败率，作为测试结果的重要参考。
Total transferred: 103314 bytes //总共传输的数据量，指的是ab从被测服务器接收到的总数据量，包括index.html的文本内容和请求头信息。
HTML transferred: 22700 bytes //从服务器接收到的index.html文件的总大小，等于Document Length＊Complete requests＝227 bytes＊100＝22700 bytes
Requests per second: 91.50 [#/sec] (mean) //平均(mean)每秒完成的请求数：QPS，这是一个平均值，等于Complete requests/Time taken for tests=100/1.093=91.50
Time per request: 109.287 [ms] (mean) //从用户角度看，完成一个请求所需要的时间（因用户数量不止一个，服务器完成10个请求，平均每个用户才接收到一个完整的返回，所以该值是下一项数值的10倍。）
Time per request: 10.929 [ms] (mean, across all concurrent requests)// 服务器完成一个请求的时间。
Transfer rate: 92.32 [Kbytes/sec] received //网络传输速度。对于大文件的请求测试，这个值很容易成为系统瓶颈所在。要确定该值是不是瓶颈，需要了解客户端和被测服务器之间的网络情况，包括网络带宽和网卡速度等信息。
Connection Times (ms)
min mean[+/-sd] median max
Connect: 47 74 12.9 74 106
Processing: 9 32 20.2 32 106
Waiting: 9 29 19.1 27 98
Total: 66 106 20.8 106 195
//这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络链接（Connect），系统处理（Processing）和等待（Waiting）三个部分。表中min表示最小值； mean表示平均值；[+/-sd]表示标准差（Standard Deviation） ，也称均方差（mean square error），这个概念在中学的数学课上学过，表示数据的离散程度，数值越大表示数据越分散，系统响应时间越不稳定。 median表示中位数； max当然就是表示最大值了。
//需要注意的是表中的Total并不等于前三行数据相加，因为前三行的数据并不是在同一个请求中采集到的，可能某个请求的网络延迟最短，但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了195ms，这个数据可以在下面的表中得到验证。
Percentage of the requests served within a certain time (ms)
50% 106
66% 109
75% 111
80% 114
90% 118
95% 154
98% 176
99% 195
100% 195 (longest request)
//这个表第一行表示有50%的请求都是在106ms内完成的，可以看到这个值是比较接近平均系统响应时间（第一个Time per request: 109.287 [ms] (mean) ）
以此类推，90%的请求是小于等于118ms的。刚才我们看到响应时间最长的那个请求是195ms，那么显然所有请求（100%）的时间都是小于等于195毫秒的，也就是表中最后一行的数据肯定是时间最长的那个请求（longest request）。
通过以上说明相信大家都能明白这些数据的意义了。如有错误还请留言指正。
一、什么是压力测试
压力测试是通过不断向被测系统施加“压力”，测试系统在压力情况下的性能表现，考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在，也就是我们可以模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。
压力/负载/性能测试之间的区别
压力测试（StressTesting），也称为强度测试，通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。压力测试需要确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。
负载测试（Load Testing）通常被定义为给被测系统加上它所能操作的最大任务数的过程，负载测试有时也会被称为“容量测试”或者“耐久性测试/持久性测试”，其目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。对于WEB应用来讲，负载则是并发用户或者HTTP连接的数量。负载测试通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
性能测试（PerformanceTesting）的目的不是去找系统Bugs，而是排除系统的性能瓶颈，并为回归测试建立一个基准。而性能测试的操作，实际上就是一个非常小心受控的测量分析过程：“运行负载试验->测度性能->调试系统”。在理想的情况下，被测应用在这个时候已经是足够稳定，所以这个过程得以顺利进行。性能测试还有另一个目标就是建立一组被测系统的基准数据。应用在网络上的性能测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。
虽然三种测试的目的截然不同，但其测试操作的环节都是基本一致的，因此一次测试过程中完全可以包含性能测试、负载测试、压力测试三个方面的内容，所使用的测试工具往往大同小异。
二、如何实现压力测试
压力测试需要对应的工具支持，测试工具有很多，详见链接。
压力测试工具
今天， 我们的主题是用ab工具来完成压力测试。
2.1 安装 ab
(1) Windows 环境安装ab
https://blog.csdn.net/foreverling_ling/article/details/81667857
(2) Linux 环境安装ab
yum -y install httpd-tools
(3) 安装成功后，检查版本号
ab -V
2.2 使用ab
ab -n 1000 -c 10 www.baidu.com/
-n 表示请求总数， -c 表示并发数， 后面跟上需要测试的接口
更多详细参数，请参考：
https://blog.csdn.net/wang404838334/article/details/78458828
三、测试案例
实际项目中使用ab，根据场景不同，使用方法有差别，也会碰到各种错误信息。
接下来我们选取了GET, POST分别做压力测试，介绍了如何携带cookie, 如何发送请求体等。
（1）测试GET 接口，需要cookie
ab -n 5000 -c 500 -C uin=7000000；session=99999999 url
其中 -C代表请求携带的cookie信息；若有多个cookie， windows上用分号分割， linux用逗号分割。
测试结果
分析
3k请求，300并发，总耗时50.93s, 每个耗时16.97ms， qps 58.9， 性能一般。
我们可以修改请求数量，并发数量，查看系统运行状况，响应时间来判断接口性能瓶颈。
（2）测试POST接口，需要JSON格式请求体
ab -n 5000 -c 300 -p post.txt -T 'application/json' url
其中，-p 表示需要携带的请求体，一般是.txt格式文件，文件内容如下：
{"toBank":"123456"}; -T 表示请求体格式，一般为’application/json’
测试结果
（1） windows 报错，初步判断ab在windows上不支持post 接口。 错误内容如下：
ab：Counld not stat POST data file (post.txt): Partial results are valid but processing is incomplete
（2）linux 上运行成功
分析
5k 请求，300并发，总耗时6.75s，平均每个请求耗时1.35ms，qps 740.7，性能良好。
同理，我们可以修改并发数，请求数来测试接口性能 ，需要注意的一般数据库写的操作并发数相对较低。
四、测试中可能遇到的错误
Windows 环境测试post接口报错
错误消息： Counld not stat POST data file (post.txt): Partial results are valid but processing is incomplete
错误原因： windows环境暂不支持用ab来测试post接口
解决方法： 使用linux环境，测试post请求一切正常，请求体支持application/json格式
Linux 环境并发数1500以上，运行报错
错误消息： socket：Too many open files (24)
错误原因： 进程打开了超过系统限制的文件数量以及通讯链接数，默认值是1024，使用ulimit -n 就可以查看。
解决方法： 设置较大的系统最大文件数量值，如： ulimit -n 2048
参考链接： too many open files(打开的文件过多)解决方法
Linux 环境并发数3000，运行报错
错误消息： Connection timed out (110)
错误原因： 连接超时
解决方法： 接口服务系统支持有限，不支持这么多并发，优化系统
五、参考链接 ab命令做压测测试 使用ab 进行并发压力测试 ab,qps,服务器性能压力 too many open files(打开的文件过多)解决方法 --------------------- 作者：Bob丶抱抱 来源：CSDN 原文：https://blog.csdn.net/bob_baobao/article/details/83544275 版权声明：本文为博主原创文章，转载请附上博文链接！