在公司业务高速增长的大前提下，我重新开始关注专项测试。在和架构师讨论过后，接下来会优先关注性能测试，其中包括两个核心工具：Apache Jmeter和Apache Bench。在此前的工作中，我只用过LR（Loadrunner）工具来进行性能测试，但是这个工具我个人感觉并不轻量，使用起来要花费大量人力物力。相对而言，Jmeter和Bench这两种工具轻量化，更适合中小企业使用。Apache Jmeter在以前的接口测试时候使用过，在现业务里应该也会作为压测工具。但毕竟是对Jmeter有过接触，所以我决定先了解Apache Bench。
Apache Bench 是 Apache 服务器的一个web压力测试工具，简称ab（是的，你没有听错，我当初也以为是Angelababy来着）。ab也是一个命令行工具，对发起负载的本机要求很低，根据ab命令可以创建很多的并发访问线程，模拟多个访问者同时对某一个URL地址进行访问，因此可以用来测试目标服务器的负载压力。总体来说，ab工具小巧简单，上手学习较快，可以提供需要的基本性能指标；但是缺点就是没有图形化结果，不能监控。
要使用ab，首先要下载Apache服务器，从Apache官网首页可以找到下载的页面。但是目前网上大都是针对linux下ab的使用，我这里需要在Windows环境下进行ab的安装与使用。但是Apache官方只提供Apache的源码版，也就是source版，而不提供二进制版（Binaries）。一般来说各个平台下的Binaries版本都是一些社区或其它网站提供的，我们在Windows上使用ab，肯定要用已经编译好的版本。想获取二进制版本，可以在ApacheHaus、Apache Lounge、BitNami WAMP Stack、WampServer、XAMPP选择一个网站来下载，我个人亲测Apache Lounge可用，具体地址如下：Apache Lounge下载地址 。
进入页面之后，根据自己需要下载32位和64位版本。这里要注意的是，要正常运行Apache 2.4 的话，需要先安装最新版C++ Redistributable Visual Studio 2017组件，也可以在这个页面进行下载。组件安装完成之后，把下载好的Apache解压，会发现里面有个ReadMe的文档，一定要好好看一下，涉及到安装环境和注意事项。
从文档中可以看到，Apache需要解压在一个盘符的根目录下，这就是所谓的“ServerRoot”，默认是配置在：{Apache24}\conf\httpd.conf这个文件中的。
但是从httpd.conf可以看出，默认配置的ServerRoot是放在了C盘（C:/Apache24），所以我把文件解压放到C盘（如果放到D盘还是无法运行的）。这些步骤准备好了之后，就可以运行bin目录下的httpd.exe文件，运行之后后台服务就启动了，这时候在浏览器中输入：http://localhost/，如果能够看到测试页面，就说明服务启动成功了。
这时候我要开始使用Apache Bench的功能了，在命令行下跳转到bin目录下，运行ab.exe就能够看到提示信息了：
这里可以注意到一个用法说明：Usage: ab.exe [options] [http://]hostname[:port]/path。也就是说，一定要在需要测试的url末尾加一个path，否则测试时会认为url非法。
这里我先尝试一下对百度首页进行一个请求总数为1000，本次请求并发数为500的测试，测试结果如下：
可以看到，如图列出了“请求命令”、“测试结果主体”、“所测试数据返回时间的百分比”，其中，“测试结果主体”里面，具体的参数为：
Concurrency Level: 并发量。（500）
Time taken for tests: 整个测试所用的时间。（34.809 s）
Complete requests: 完成的请求数。（1000）
Failed requests: 失败的请求数。（0）
Non-2xx responses: 如果接收到的HTTP响应数据的头信息中含有2XX以外的状态码，则会在测试结果中显示另一个名为“Non-2xx responses”的统计项，用于统计这部分请求数（这些请求并不算在失败的请求中）。（1000）
Total transferred: 表示所有请求的响应数据长度总和，包括每个HTTP响应数据的头信息和正文数据的长度。（502000 bytes）
HTML transferred: 表示所有请求的响应数据中正文数据的总和，也就是减去了Total transferred中HTTP响应数据中的头信息的长度。（222000 bytes）
Requests per second(RPS): 吞吐率。要清楚吞吐率是与并发数相关的，即使请求总数相同，但如果并发数不一样，吞吐率还是很可能有很大差异的。 （28.73【#/second】）
计算公式：Complete requests/Time taken for tests
Time per request(mean): 用户平均请求等待时间。也就是一次并发总的时间。 （17404.500 ms）
计算公式：Time token for tests/（Complete requests/Concurrency Level）。
Time per request(mean, across all concurrent requests): 服务器平均请求等待时间。也就是一次请求（在本例中也就是500中的平均每一次）所需时间。 （34.809 ms）
计算公式：Time taken for tests/Complete requests ; 也可以这么统计：Time per request/Concurrency Level。
Transfer rate: 表示这些请求在单位时间内从服务器获取的数据长度。 （14.08 Kbytes/sec）
计算公式：Total trnasferred/ Time taken for tests
这个统计很好的说明服务器的处理能力达到极限时，其出口宽带的需求量。
Percentage of requests served within a certain time (ms) : 这部分数据用于描述每个请求处理时间的分布情况，比如以上测试，80%的请求处理时间都不超过6ms，这个处理时间是指前面的Time per request，即对于单个用户而言，平均每个请求的处理时间。
更多命令参数参考：
总体体验下来，具有轻量化特点的bench还是很适合中小企业使用，尤其在于模拟访问页面的多机测试。最后，希望更多行业大牛可以多多给我指教和交流，助我一起成长。
读更多的好书，拍更美的照片，写更酷的代码，遇见更有趣的人，愿望是实现从IT菜鸟到全栈工程师的蜕变。
