常用的性能测试工具有：JMeter、loadRunner、ab；对于开发人员来说用的多的是免费的Jmeter和ab，对于测试来说可能用收费的商业软件loadRunner多。在这里我们就说说ab压测工具，因为ab基本满足web接口测试要求，jmeter后面再看要不要写一篇，loadRunner就暂不考虑。
ab简介（Apache Benchmark）
Apache Benchmark(简称ab) 是Apache安装包中自带的压力测试工具 ，简单易用。 使用起来非常的简单和方便。 不仅仅是可以apache服务器进行网站访问压力测试，还可以对其他类型的服务器进行压力测试。 比如nginx,tomcat,IIS等
ab的原理（同jmeter）
ab的原理：ab命令会创建 多个并发 访问线程，模拟 多个访问者 同时对某一 URL地址 进行访问。
它的测试目标是基于URL的，因此，它既可以用来测试apache的负载压力，也可以测试nginx、lighthttp、tomcat、IIS等其它Web服务器的压力。
ab是一个命令行工具， ab命令对发出负载的计算机要求很低，它既不会占用很高CPU，也不会占用很多内存。但却会给目标服务器造成巨大的负载，其原理类似CC攻击。自己测试使用也需要注意，否则一次上太多的负载。可能造成目标服务器资源耗完，严重时甚至导致死机。
总的来说ab工具小巧简单，上手学习较快，可以提供需要的基本性能指标，但是没有图形化结果，不能监控。
ab、JMeter分别是用C、Java开发的、都是 Apache 下的测试软件，基于多线程并发模型的压测工具，也是目前最流行的开源压测工具，两者的工作原理类似。
-
不管ab还是JMeter，其所谓的虚拟用户(vuser)就是对应一个线程
-
在单个线程中，每个请求（query）都是同步调用的，下一个请求要等待前一个请求完成才能进行
-
一个请求（query）分成三部分：
- send - 施压端发送开始，直到承压端接收完成
- wait - 承压端接收完成开始，直至业务处理结束
- recv - 承压端返回数据，直至施压端接收完成
-
同一线程中连续的两个请求之间存在等待时间这种概念，即图中的空白处
总的来说，多线程模型的优劣势总结有如下 ：
（1）重度依赖于开发语言和操作系统对多线程的支持
（2）多线程切换的时候资源消耗比较多，在同等资源的情况下，产生的有效并发数量小；
（3）多线程也相对容易产生错误，比如死锁，共享数据错乱；
（4）可以通过丰富的界面来减少二次开发导致上面的一些错误；
（5）通过扩展开发和插件实现分布式来满足并发量的不足；
（6）多线程的应用技术比较成熟，未来相当长时间，还会继续应用于很多性能测试工具。
（7）从应用角度来看，基于多线程的并发模型，往往需要设置最大并发数参数，而如果压测场景需要不断往上加压，那这类工具其实挺难应付的
安装
windows : 解压即可用 https://www.apachelounge.com/download/VS17/binaries/httpd-2.4.59-240404-win64-VS17.zip
ubuntu安装ab : sudo apt-get install apache2-utils
centOS7 安装ab : yum -y install httpd-tools
centos6.5 默认已安装了abwindows安装下载地址：Apache VS17 binaries and modules download
参数说明
命令格式 ab [options] [http://]hostname[:port]/path
比较常用的有 -n， -t ， -c
-c（concurrency）表示用多少并发来进行测试
-t表示测试持续多长时间
-n表示要发送多少次测试请求
GET请求：
ab -n 100 -c 10 http://example.com/page
POST请求：
ab -n 100 -c 10 -T application/json -p payload.json http://example.com/api
可以使用 ab -h 来查看基准参数。
-n 即requests，用于指定压力测试总共的执行次数。
-c 即concurrency，用于指定的并发数。
-t 即timelimit，等待响应的最大时间(单位：秒)。
-b 即windowsize，TCP发送/接收的缓冲大小(单位：字节)。
-p 即postfile，发送POST请求时需要上传的文件，此外还必须设置-T参数。
-u 即putfile，发送PUT请求时需要上传的文件，此外还必须设置-T参数。
-T 即content-type，用于设置Content-Type请求头信息，例如：application/x-www-form-urlencoded，默认值为text/plain。
-v 即verbosity，指定打印帮助信息的冗余级别。
-w 以HTML表格形式打印结果。
-i 使用HEAD请求代替GET请求。
-x 插入字符串作为table标签的属性。
-y 插入字符串作为tr标签的属性。
-z 插入字符串作为td标签的属性。
-C 添加cookie信息，例如："Apache=1234"(可以重复该参数选项以添加多个)。
-H 添加任意的请求头，例如："Accept-Encoding: gzip"，请求头将会添加在现有的多个请求头之后(可以重复该参数选项以添加多个)。
-A 添加一个基本的网络认证信息，用户名和密码之间用英文冒号隔开。
-P 添加一个基本的代理认证信息，用户名和密码之间用英文冒号隔开。
-X 指定使用的代理服务器和端口号，例如:"126.10.10.3:88"。
-V 打印版本号并退出。
-k 使用HTTP的KeepAlive特性。
-d 不显示百分比。
-S 不显示预估和警告信息。
-g 输出结果信息到gnuplot格式的文件中。
-e 输出结果信息到CSV格式的文件中。
-r 指定接收到错误信息时不退出程序。
-h 显示用法信息，其实就是ab -help。压测报告解读
ab -n 1000 -c 100 -r http://www.baidu.com/s?ie=UTF-8&wd=%E6%88%91%E7%88%B1%E4%B8%AD%E5%9B%BD
ab模拟 （ -n 1000 -c 100 ）100个客户端并发请求1000次百度
D:\Program Files\httpd-2.4.59-240404-win64-VS17\Apache24\bin>ab -n 1000 -c 100 -r http://www.baidu.com/s?ie=UTF-8&wd=%E6%88%91%E7%88%B1%E4%B8%AD%E5%9B%BD
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
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: BWS/1.1
Server Hostname: www.baidu.com 请求地址
Server Port: 80 端口
Document Path: /s?ie=UTF-8 请求路径
Document Length: 154 bytes 响应的数据大小
Concurrency Level: 100 并发数
Time taken for tests: 14.578 seconds 总共用时
Complete requests: 1000 完成的请求数
Failed requests: 0 失败的请求数
Non-2xx responses: 1000 接收到的HTTP响应数据的头信息中含有2XX以外的状态码请求数
Total transferred: 1097289 bytes 总共传输的字节数 包括请求头
HTML transferred: 154000 bytes html文件大小，即响应页面大小
Requests per second: 68.60 [#/sec] (mean) 每秒多少请求 即吞吐量 （重点参数）
Time per request: 1457.765 [ms] (mean) 用户平均请求等待时间
Time per request: 14.578 [ms] (mean, across all concurrent requests) 每个连接请求实际运行时间的平均值
Transfer rate: 73.51 [Kbytes/sec] received 每秒获取的数据长度，即带宽传输速度（重点参考，评估带宽）
Connection Times (ms)
最小时间，平均值，中值，最大值
min mean[+/-sd] median max
Connect: 10 14 3.7 13 37 连接时间：tcp连接
Processing: 22 1371 260.1 1437 1539 处理时间：服务端业务处理时间
Waiting: 22 724 419.9 722 1522 等待时间：网络延迟
Total: 41 1386 260.2 1451 1553 总计时间
1386ms=14ms+1371ms+724ms 服务端处理时间是1.271秒，网络延迟时间0.724秒
Percentage of the requests served within a certain time (ms)
50% 1451 50%的请求都在1.451ms内响应完成
66% 1475 60%的请求都在1.475ms内响应完成
75% 1489
80% 1496
90% 1513
95% 1527
98% 1537
99% 1549 99%的请求都在1.549ms内响应完成
100% 1553 (longest request)
D:\Program Files\httpd-2.4.59-240404-win64-VS17\Apache24\bin>
其他参数说明
Failed requests: 77600 #错误请求数
(Connect: 0, Receive: 25782, Length: 26036, Exceptions: 25782)
Receive:当客户端connect成功后，并且服务端成功accept，并且没有开始recv，然后服务端close掉socket，就产生这个错误（平时多见于服务端主动close掉客户端连接，即客户端表现为Connection reset by peer）
Length：即读到的报文长度不等于http头的content-length值（c->bread != doclen）。当读到的报文长度c->bread等于0时，并且apr_socket_recv返回APR_EOF，意味着服务端成功accept，并且已经开始接收（可能已经接收完整个报文，也可能没有），但因业务繁忙，来不及处理已经接收的报文，当服务端发现报文已经超过设定的过期时间，就close掉socket。
Exceptions：多见于网络发生错误，导致监听的事件出现APR_POLLERR，分以下两种情况:
err_except发生在revc阶段，即出现事件（APR_POLLERR<指定的文件描述符发生错误>或者APR_POLLNVAL<指定的文件描述符非法>）,一般常见是POLLERR。在读取数据阶段出现Resource temporarily unavailable，服务端close掉socket，read_connection后会产生APR_POLLERR事件，导致err_except+1。上面的Length 错误不一定会引发err_except（此问题还未解决）。
err_except发生在connect阶段，即出现事件（APR_POLLERR），并且错误描述为Operation now in progress，并且所有的并发socket都已经建立（destsa->next==0），导致err_except+1。这个貌似不太合理。对于定长网页的访问，出现Failed requests多由于网络，或者服务端主动行为造成的。
压测耗时说明
Jmeter和ab对比
| jemeter | ab |
| jmeter是一次完整的请求和返回 | AB只是发出去请求，并不对返回做处理； 所以从准确性来说，Jmeter更准确，而AB速度更快，可以用最少的机器资源产生更多的访问请求； |
| jmeter可以提供更加详细的统计结果数据，比如接口错误信息、单线程的请求时间等，而AB则不支持； | ab的结果为用数学方式统计平均值 |
| jmeter支持可变参数和CSV数据集的输入，能设定更加负责的测试样例 | AB不需要写配置文件 |
| jmeter不支持精确时间的压测，比如压测10分钟 | AB支持 |
| jmeter为GUI的较重，并且统计了很多结果数据，比AB耗时耗费资源多，Jmeter由于比较重，且统计了很多结果数据，比AB耗时耗费资源多，AB属于超轻量级，在开发测试过程中十分适合做单接口压测。 | AB属于轻量级 |
| Jmeter支持分布式的压测集群，且支持函数，AB不支持； | AB不支持； |
Jmeter和loadrunner对比
| 对比 | LoadRunner Enterprise | Jmeter |
| 运行原理 | 通过中间代理,监控&收集并发客户端发现的指令，生成脚本，发送到应用服务器，监控服务器反馈的结果 | 通过中间代理,监控&收集并发客户端发现的指令，生成脚本，发送到应用服务器，监控服务器反馈的结果 |
| 场景配置 | 通过在场景中设置场景，选择虚拟用户数，配置简单，更逼近真实业务场景 | 通过增加线程组的数目，或者是设置循环次数来增加并发用户，需通过逻辑控制器去实现复杂的测试行为 |
| 安装过程 | LoadRunner Enterprise无需安装部署测试场景、测试分析相关工具组件，只需要安装测试脚本开发工具组件 | 需要安装配置JDK，解压jmeter文件到本地磁盘进行安装 |
| 操作界面 | 测试脚本开发需要使用本地安装软件，测试场景、测试结果等其他功能通过浏览器操作，操作简便 | 全部功能需要本地安装软件进行操作，操作步骤较为繁琐 |
| 协议支持 | 支持行内几乎所以协议 | 虽然可以支持HTTP/HTTPS、FTP、SOAP、JMS等多种协议，但还是无法以原生方式支持某些重要的协议，例如SMTP、IMAP等。 |
| 分布式中间代理 （用于获取更多的并发用户数） | 支持 | 支持 |
| IP欺骗功能 （用于模拟真实的业务环境） | 支持 | 不支持 |
| 脚本开发 | 脚本录制简单，有比较强的脚本增强功能，支持抓包工具抓包结果转换为测试脚本 | 需要借助外部工具进行脚本录制，脚本增强功能相对较弱，许多参数需利用插件捕获后，手工增加 |
| 资源监控 | 资源监控功能相对完善，支持SNMP收集资源指标 | 需要安装资源监控插件 |
| 报告分析 | 结果丰富，测试结果指标数据种类较多 | 结果较少，一些参数要另外写脚本记录服务器的性能 |
| 报告呈现 | 支持生成多种文件格式报告 | 简单图表 |
| 稳定性 | 稳定性高，结果更加准确 | 稳定性稍差 |
