ab压力测试工具

吞吐率（Requests per second） 概念：服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。 计算公式：总请求数 / 处理完成这些请求数所花费的时间，即 Request per second = Complete requests / Time taken for tests QPS（每秒查询数）、TPS（每秒事务数）是吞吐量的经常使用量化指标，另外还有HPS（每秒HTTP请求数）。 跟吞吐量有关的几个重要是：并发数、响应时间。 QPS（TPS），并发数、响应时间它们三者之间的关系是： QPS（TPS）= 并发数/平均响应时间 对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）能够很好地度量系统的性能，但对于并发系统，一般须要用吞吐量做为性能指标。 　对于一个多用户的系统，若是只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每一个用户看到的响应时间一般并非n×t，而每每比n×t小不少（固然，在某些特殊状况下也可能比n×t大，甚至大不少）。
 这是由于处理每一个请求须要用到不少资源，因为每一个请求的处理过程当中有许多不走难以并发执行，这致使在具体的一个时间点，所占资源每每并很少。也就是说在处理单个请求时，在每一个时间点均可能有许多资源被闲置，当处理多个请求时，
 若是资源配置合理，每一个用户看到的平均响应时间并不随用户数的增长而线性增长。实际上，不一样系统的平均响应时间随用户数增长而增加的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要缘由。通常而言，吞吐量是一个比较通用的指标，两个具备不一样用户数和用户使用模式的系统，
 若是其最大吞吐量基本一致，则能够判断两个系统的处理能力基本一致。

并发链接数（The number of concurrent connections） 概念：某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。

并发用户数（The number of concurrent users，Concurrency Level） 概念：要注意区分这个概念和并发链接数之间的区别，一个用户可能同时会产生多个会话，也即链接数。 并发用户数是指系统能够同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个很是不许确的指标，由于用户不一样的使用模式会致使不一样用户在单位时间发出不一样数量的请求。
 一网站系统为例，假设用户只有注册后才能使用，但注册用户并非每时每刻都在使用该网站，所以具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花不少时间阅读网站上的信息，于是具体一个时刻只有部分在线用户同时向系统发出请求。
 这样，对于网站系统咱们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。因为注册用户可能长时间不登录网站，使用注册用户数做为性能指标会形成很大的偏差。而在线用户数和同事发请求用户数均可以做为性能指标。
 相比而言，以在线用户做为性能指标更直观些，而以同时发请求用户数做为性能指标更准确些。

用户平均请求等待时间（Time per request） 计算公式：处理完成全部请求数所花费的时间/ （总请求数 / 并发用户数），即 Time per request = Time taken for tests /（ Complete requests / Concurrency Level）

服务器平均请求等待时间（Time per request: across all concurrent requests） 计算公式：处理完成全部请求数所花费的时间 / 总请求数，即 Time taken for / testsComplete requests 能够看到，它是吞吐率的倒数。 同时，它也=用户平均请求等待时间/并发用户数，即Time per request / Concurrency Level

QPS每秒查询率(Query Per Second) 　　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，做为域名系统服务器的机器的性能常常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也便是最大吞吐能力。 （看来是相似于TPS，只是应用于特定场景的吞吐量）

响应时间(RT) 　　响应时间是指系统对请求做出响应的时间。直观上看，这个指标与人对软件性能的主观感觉是很是一致的，由于它完整地记录了整个计算机系统处理请求的时间。因为一个系统一般会提供许多功能，而不一样功能的处理逻辑也千差万别，于是不一样功能的响应时间也不尽相同，
 甚至同一功能在不一样输入数据的状况下响应时间也不相同。因此，在讨论一个系统的响应时间时，人们一般是指该系统全部功能的平均时间或者全部功能的最大响应时间。固然，每每也须要对每一个或每组功能讨论其平均响应时间和最大响应时间。 　　对于单机的没有并发操做的应用系统而言，人们广泛认为响应时间是一个合理且准确的性能指标。须要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来讲，响应时间小于100毫秒应该是不错的，
 响应时间在1秒左右可能属于勉强能够接受，若是响应时间达到3秒就彻底难以接受了。而对于编译系统来讲，完整编译一个较大规模软件的源代码可能须要几十分钟甚至更长时间，但这些响应时间对于用户来讲都是能够接受的。

安装ab测试工具

yum install httpd-tools -y

ab工具帮助
  ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒能够处理多少个请求。

命令格式： ./ab [options] [http://]hostname[:port]/path 命令参数： -A：指定链接服务器的基本的认证凭据； -c：指定一次向服务器发出请求数； -C：添加cookie； -g：将测试结果输出为“gnuolot”文件； -h：显示帮助信息； -H：为请求追加一个额外的头； -i：使用“head”请求方式； -k：激活HTTP中的“keepAlive”特性； -n：指定测试会话使用的请求数； -p：指定包含数据的文件； -q：不显示进度百分比； -T：使用POST数据时，设置内容类型头； -v：设置详细模式等级； -w：以HTML表格方式打印结果； -x：以表格方式输出时，设置表格的属性； -X：使用指定的代理服务器发送请求； -y：以表格方式输出时，设置表格属性。 参数不少,通常咱们用 -c表示并发数 -n 表示请求数便可 若是只用到一个Cookie，那么只需键入命令： ab －n 100 －C key＝value http://test.com/ 若是须要多个Cookie，就直接设Header： ab -n 100 -H “Cookie: Key1=Value1; Key2=Value2” http://test.com/

使用举例：

[root@c75 ~]# ab -n 1000 -c 1000 http://192.168.255.209/monitor This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 192.168.255.209 (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: nginx/1.14.0 Server Hostname: 192.168.255.209 Server Port: 80 Document Path: /monitor Document Length: 185 bytes Concurrency Level: 1000 //并发请求数 Time taken for tests: 2.252 seconds //整个测试持续的时间 Complete requests: 1000 //完成的请求数 Failed requests: 0 //失败的请求数 Write errors: 0 //写入失败数 Non-2xx responses: 1000 //非2xx状态请求数 Total transferred: 386000 bytes //传输的总字节数大小 HTML transferred: 185000 bytes //传输的总文档字节数大小 Requests per second: 444.05 [#/sec] (mean) //每秒处理的请求数 Time per request: 2252.008 [ms] (mean) //每一个请求花费的平均时间 Time per request: 2.252 [ms] (mean, across all concurrent requests) Transfer rate: 167.39 [Kbytes/sec] received //转移率 Connection Times (ms) min mean[+/-sd] median max Connect: 6 40 14.2 36 69 //建立TCP链接到服务器或者代理服务器所花费的时间 Processing: 40 738 722.9 302 2138 //写入缓冲区消耗+链路消耗+服务端消耗 Waiting: 11 546 595.8 293 1930 //写入缓冲区消耗+链路消耗+服务端消耗+读取数据消耗 Total: 45 778 733.0 344 2207 //总花费时间 Percentage of the requests served within a certain time (ms) 50% 344 66% 752 75% 1668 80% 1799 90% 1957 95% 2073 98% 2161 99% 2191 100% 2207 (longest request)