一般来说核心页面都需要进行压测，特别是秒杀页面，从而知道网站的承受能力，方便暴露一些问题，更好的把控网站。压测工具有很多种，最简单、方便的可以使用ApacheBench，也就是我们熟悉的ab工具，不过只能做一些简单的压测效果。
如果在windows下面压测，安装apache后，bin目录下会有个“ab.exe”；linux下则需要另行安装，拿centos举例可以执行“yum install httpd-tools”进行安装。安装完成后执行“ab”命令就可以看到提示了。
压测命令：ab -kc 10 -n 100 https://www.daixiaorui.com/
参数说明：
k：使用长连接（http keep-alive）。
c：并发数。
n：请求数。
压测结果如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
|
我们主要看这一项：Requests per second: 35.65 [#/sec] (mean)。意思是一秒钟处理的请求数，即代潇瑞博客一秒钟能接受35.65个请求。
不过压测结果还依赖于网络带宽、当前负载等情况的影响。就拿我的网站来说，在远程压测才4.37个请求，因为服务器只有1MB的带宽，即128kb/s左右。
一句话解释并行和并发的概念和异同。
并发：时间段内有很多的线程或进程在执行，但何时间点上都只有一个在执行，多个线程或进程争抢时间片轮流执行。不是一个时间点的，是一个时间段内的概念，比如一秒钟能处理多少请求，请求数越多表示并发量越大。
并行：时间段和时间点上都有多个线程或进程在执行。就好比下图一样的关系：
咖啡机表示CPU，并发就是两个队列交替使用一台咖啡机，并行是两个队列同时使用两台咖啡机。
关于上面标红文字“时间点”的解释：
cpu并不能同时处理多件任务（拿一个核心来说），我们平时用电脑的时候，既能下载、又能同时听歌、还能同时浏览网页，是因为CPU在处理的程中，会把时间分成很多片段（纳秒或微秒级别），然后让程序轮流的执行，因为片段非常小，肉眼分辨不出来，所以让我们感觉电脑是在同时处理请求的。
文章出自：https://www.daixiaorui.com/read/254.html
ab -n 1000 -c 100 -w http://localhost/index.php >>c:\1.html
上面的测试用例表示100并发的情况下，共测试访问index.php脚本1000次，并将测试结果保存到c:\1.html文件中。
ab -n 全部请求数 -c 并发数 测试url
例:ab -n 1000 -c 50 http://www.newdev.gztest.com/
Server Software: Microsoft-IIS/7.0
Server Hostname: www.newdev.gztest.com
Server Port: 80
Document Path:
Document Length: 82522 bytes #请求文档大小
Concurrency Level: 50 #并发数
Time taken for tests: 92.76140 seconds #全部请求完成耗时
Complete requests: 10000 #全部请求数
Failed requests: 1974 #失败的请求
(Connect: 0, Length: 1974, Exceptions: 0)
Write errors: 0
Total transferred: 827019400 bytes #总传输大小
HTML transferred: 825219400 bytes //整个场景中的HTML内容传输量
Requests per second: 108.61 [#/sec] (mean) #每秒请求数(平均)//大家最关心的指标之一，相当于 LR 中的每秒事务数，后面括号中的 mean 表示这是一个平均值
Time per request: 460.381 [ms] (mean) #每次并发请求时间(所有并发) //大家最关心的指标之二，相当于 LR 中的平均事务响应时间，后面括号中的 mean 表示这是一个平均值
Time per request: 9.208 [ms] (mean, across all concurrent requests) #每一请求时间(并发平均) //每个请求实际运行时间的平均值
Transfer rate: 8771.39 [Kbytes/sec] received #传输速率//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题
Percentage of the requests served within a certain time (ms)
50% 2680
66% 2806
75% 2889
80% 2996
90% 11064
95% 20161
98% 21092
99% 21417
100% 21483 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于2680毫秒，60％ 的用户响应时间小于2806毫秒，最大的响应时间小于21417毫秒
由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数。
Connection Times (ms) #连接时间
min mean[+/-sd] median max
Connect(#连接): 0 0 2.1 0 46
Processing(#处理): 31 458 94.7 438 1078
Waiting(#等待): 15 437 87.5 422 938
Total: 31 458 94.7 438 1078
其它参数:
-n requests 全部请求数
-c concurrency 并发数
-t timelimit 最传等待回应时间
-p postfile POST数据文件
-T content-type POST Content-type
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute 加入cookie, eg. 'Apache=1234. (repeatable)
-H attribute 加入http头, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute http验证,分隔传递用户名及密码
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port 代理服务器
-V 查看ab版本
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
