### 一、压测背景
>以前:出社会前经常用:AB压自己的工具 nginx 欢迎页面，从20%到100%查看服务器资源，发现原来的开源工具可以使用4台C8G虚拟机充满压力，然后陷入沉思。低成本的压力测试可以导致虚拟机的资源充满负载，也是静态页面。如果发生在企业身上会发生什么？损失远高于压测方，后果难以想象。
>现在：我承认以前太天真了。既然有压力测试方，就必须有防御方。如果你遇到恶意压力测试他人网站，你可以直接通过各种家庭桶屏蔽和屏蔽。对于当今企业来说，每个人都认为最大的价值是探索资源性能，合理规划资源容量，提高业务稳定性SLA、减少事故的发生，这对测试或运维都是一件好事，也是价值的体现。
>未来：压力测试的普遍性，不仅为企业带来资源性能、资源容量合理规划、技术架构升级验证、业务系统在线测试、业务峰值稳定性测试等价值，通过压力测试资源能力，降低盲目估计风险，提高服务的可用性和稳定性。
#### 那为什么要做压测呢？
压力测试的目的是通过压力测试（模拟真实用户的行为）来计算机器的性能（单台机器的性能）QPS)，从而计算出系统承担指定用户数(100W)当时，需要多少机器来支持压力测试是对未来可能用户数量的估计（提前演练）。压力测试后，通过优化程序的性能或准备足够的机器来确保用户体验。
### 二、压测工具
1.工具说明
AB：ApacheBench 是 Apache服务器自带一个web压力试验工具，简称ab。ab根据另一种命令行工具，本机对启动负载的要求很低ab命令可以创建许多并发访问线程，同时模拟多个访问者URL访问地址，用于测试目标服务器的负载压力。总的来说ab压测工具小巧简单，非常轻，上手学习快，能提供所需的基本性能指标，但没有图形结果，无法监控。
Jmeter：Apache JMeter是Apache基于组织发展Java压力测试工具Web应用测试，但后来扩展到其他测试领域。JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。
LoadRunner：LR是HP通过模拟数千万用户实施并发负载和实时性能监控，推出了一种预测系统行为和性能的负载测试工具，分为Windows 版本和Unix 版本。LoadRunner能够测试整个企业结构。企业还可以最大限度地缩短测试时间，优化性能，加快应用系统的发布周期。还可以预测系统行为，优化系统性能。商业版支持录屏 脚本的方式。
阿里云PTS：PTS（Performance Testing Service）云测试工具面向所有技术背景人员。与传统工具的复杂性不同，PTS通过互联网交互，提供性能测试API各种能力，如调试和监控。自主研发和适应开源功能可以轻松模拟用户访问任何体积的业务场景，随时启动任务，避免繁琐的施工和维护成本。与监控、流控等兄弟产品紧密结合，提供一站式高可用性、高效检验和管理业务性能。当然，可以模拟黑客对业务系统进行全面深入的安全测试，
2.常用工具比较
| 对比项\压测工具 | Apache Bench（ab） | JMeter | LoadRunner | PTS |
| --- | --- | --- | --- | --- |
| 学习成本 | 低 | 高 | 高 | 低 |
| 安装部署成本 |低 | 高 | 高 | 低 |
| 费用 | 无| 无 | 有 | 有 |
| 多协议 | 否 | 是 | 是 | 是 |
| 图形化展示 |否 | 是 | 是 | 是 |
| TPS模式 | 否 | 否 | 否 | 是 |
| 压测链路、场景布局管理 | 否 | 是 | 是 | 是 |
| 场景录制 | 否 | 是 | 是 | 是 |
| 生态环境强弱 | 弱 | 弱 | 弱 | 强 |
| 监测指标是否完整 |否 | 否 | 否 | 是 |
| 定制流量区域 | 否 | 否 | 否 | 是 |
3.压测标准
| 压测类型 | 解释说明 |
| --- | --- |
| 压力测试(Stress Testing) | 也被称为强度测试，测试系统的最大抗压能力，测试系统在强负载（大数据、高并发性）下能承受的最大压力，并估计系统的瓶颈 |
| 并发测试(Concurrency Testing) | 通过模拟许多用户同时访问系统或操作系统的某个功能来测试系统的性能，发现问题（并发读写、线程控制、资源竞争） |
| 耐久性测试(Configuration Testing) | 通过测试系统和机器在大负荷条件下的长期运行，发现问题（内存泄漏、数据库连接池不释放、资源不回收） |
#### 系统性能指标
3.1 交易响应时间
>响应时间是指用户从客户端发起请求，到客户端收到从服务器端返回的响应结束的时间。在性能测试中，压力启动端到压力测试服务器返回处理结果的时间一般为秒或毫秒。平均响应时间是指同一交易的平均响应时间。一般来说，交易响应时间是指平均响应时间。 平均响应时间指标值应根据不同的交易设定，一般分为复杂的交易响应时间、简单的交易响应时间和特殊的交易响应时间。特殊交易响应时间的设定必须明确交易响应时间的特殊性。
Response Time: 简称RT
>不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：
>互联网企业:500毫秒以下，比如淘宝业务10毫秒左右。
>金融企业:1秒以下为佳，部分复杂业务3秒以下。
>保险企业：3秒以下为佳。
>制造业：5秒以下为佳。
批量交易：
>时间窗口：即整个压力测量过程的时间，不同数据量的时间不同，如双11和99推广，不同数据量级的时间窗口不同。在大数据量的情况下，压力测量可以在2小时内完成。
3.2 系统处理能力
>系统处理能力是指使用系统硬件平台和软件平台进行信息处理的能力。 系统处理能力通过系统每秒处理的交易数量进行评估。对交易有两种理解：一是业务人员视角的业务流程；二是系统视角的交易应用和响应流程。前者称为业务交易过程，后者称为事务。两个交易指标都可以评估应用系统的处理能力。一般建议与系统交易日志保持一致，以便统计业务量或交易量。在技术测试活动中，系统处理能力指标是重要指标。
一般用以下指标来衡量：
>HPS（Hits Per Second） ：每秒点击次数，单位为次/秒。
>TPS（Transaction per Second）：系统每秒处理交易数，单位为笔/秒。
>QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。 在互联网业务中，如果有些业务有并且只有一个请求连接，那么TPS=QPS=HPS，一般情况下使用TPS用来衡量整个业务流程，QPS用来衡量接口查询的次数HPS表示单击服务器请求。
标准
>无论TPS、QPS、HPS，根据经验，这一指标是衡量系统处理能力的一个非常重要的指标。
>金融行业：1000 TPS~50000 TPS，不包括互联网活动。
>保险行业：100 TPS~100000 TPS，不包括互联网活动。
>制造行业：10 TPS~5000 TPS。
>互联网电子商务：1万 TPS~1000000 TPS。
>中型互联网网站：1万 TPS~50000 TPS。
>小型互联网网站：5000 TPS~10000 TPS。
3.3 并发用户
>并发用户数是指同时登录系统并进行业务操作的用户数。 长连接系统并发用户数最大的并发用户数是系统的并发接入能力。对于短连接系统来说，最大并发用户数不等于系统的并发接入能力，而是与系统架构、系统处理能力等情况有关。比如系统吞吐能力强，短连接一般都有连接复用，并发用户数往往大于系统并发接入数。因此，对于大多数短连接系统，吞吐量模式（RPS模式，Request Per Second）也是阿里最好的实践，PTS支持RPS模式压力测量、吞吐量压力测量结构和测量一步到位。 在测试中，虚拟用户被用来模拟实际用户的业务操作。
Virtual User：简称VU
标准
>一般来说，性能测试是测量系统处理能力容量，而不是测试并发用户数量，除了服务器长连接可能影响并发用户数量接外，系统处理能力不受并发用户数量的影响。系统处理能力容量可以用最小用户数测试，系统处理能力容量可以用更多用户测试。
3.4 错误率
定义及解释
>错误率是指系统在负载下失败的概率。错误率=(失败交易数/总交易数)×100%。稳定性好的系统，其错误率应由超时引起，即超时率。
Virtual Failure Ratio：简称FR: VU
标准
>不同的系统对错误率有不同的要求，但一般不超过千分之六，即成功率不低于99.4%。
3.5 CPU
定义及解释
>中央处理器是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。其功能主要是解释计算机指令和处理计算机软件中的数据。CPU Load：测量系统正在工作的数量度。平均负载。
简称
>Central Processing Unit：CPU
标准
>CPU指标主要是指CPU利用率和利用率包括用户状态（user）、系统态（sys）、等待态（wait）、空闲态（idle）。CPU利用率和利用率低于行业警戒值，即小于或等于75%，CPUsys%小于或者等于30%，CPU wait%小于或者等于5%。单核CPU也需遵循上述指标要求。CPU Load要小于CPU核数。
3.6 Memory
定义及解释
>内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。
简称
>Memory就是内存的简称。
标准
>现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%，太多的交换将会引起系统性能低下。
3.7 磁盘吞吐量
定义及解释
>磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量。
简称
>Disk Throughput。
标准
>磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，一般情况下，磁盘繁忙率要低于70%。
3.8 网络吞吐量
定义及解释
>网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。
简称
>Network Throughput
标准
>网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。
3.9 内核参数
操作系统内核参数主要包括信号量、进程、文件句柄，一般不要超过设置的参数值即可，具体如下：
|一级指标 | 二级指标 |单位| 解释|
| --- | --- | --- |---|
|内核参数 |Maxuprc| 个 |限制每个用户的用户进程的最大数量|
||Max_thread_proc |个 |定义每个进程允许的最大线程数量|
||Filecache_max| 字节| 最大可用于cache file I/O的物理内存|
||Ninode| 个 |内存中HFS文件系统打开i节点的最大数量|
||Nkthread| 个 |限制允许同时运行的线程数量|
||Nproc |个| 限制允许同时运行的进程数量|
||Nstrpty |个| 基于STREAMS的伪终端 （pts） 的最大数量|
||Maxdsiz |字节| 任何用户进程的数据段的最大大小（以字节为单位）|
||maxdsiz_64bit| 字节| 任何用户进程的数据段的最大大小（以字节为单位）|
||maxfiles_lim |个 |每个进程的文件描述符的最大数目硬限制|
||maxssiz_64bit |字节 |任何用户进程的堆栈的最大大小|
||Maxtsiz |字节| 任一用户进程的文本段的最大大小|
||nflocks |个 |文件锁的最大数量|
||maxtsiz_64bit |字节| 任一用户进程的文本段的最大大小|
||msgmni |个| 系统级System V IPC消息队列 （ID) 所允许的最大数量|
||msgtql |个| 系统中任意时间的最大System V IPC消息数|
||npty |个 |BSD伪终端 （pty） 的最大数量|
||nstrtel |个| 指定内核可支持传入telnet会话的telnet设备文件的数量|
||nswapdev |个| 可用于交换的设备的最大数量|
||nswapfs |个| 可用于交换的文件系统的最大数量|
||semmni |个| System V IPC系统级信号量标识符的数量|
||semmns |个| System V系统级信号量的数量|
||shmmax |字节| System V共享内存段的最大大小|
||shmmni |个| 系统中System V共享内存段标识符的数量|
||shmseg |个| 每个进程System V共享内存段的最大数量|
#### 中间件指标
1.定义及解释
常用的中间件例如Tomcat、Weblogic等指标主要包括JVM、ThreadPool、JDBC，具体如下：
|一级指标| 二级指标| 单位| 解释|
|---|---|---|---|
|GC |GC频率| 每秒多少次 |Java虚拟机垃圾部分回收频率|
|Full |GC频率 |每小时多少次 |Java虚拟机垃圾完全回收频率|
|Full |GC平均时长| 秒 |用于垃圾完全回收的平均时长
|Full |GC最大时长| 秒| 用于垃圾完全回收的最大时长|
|堆使用率 |百分比|%| 堆使用率|
|ThreadPool| Active Thread Count| 个 |活动的线程数|
|Pending |User Request |个 |处于排队的用户请求个数|
|JDBC |JDBC Active Connection |个 |JDBC活动连接数|
2.标准
* 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。
* 当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。
* GC频率不能频繁，特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大堆大小分别设置1024 M比较合适。
#### 数据库指标
1.定义及解释
常用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等，具体如下：
|一级指标| 二级指标 |单位 |解释|
|---|---|---|---|
|SQL| 耗时 |微秒| 执行SQL耗时|
|吞吐量| QPS |个| 每秒查询次数|
||TPS 个| 每秒事务次数|
|命中率| Key Buffer命中率| 百分之| 索引缓冲区命中率|
||InnoDB Buffer命中率| 百分之 |InnoDB缓冲区命中率|
||Query Cache命中率 |百分之| 查询缓存命中率|
||Table Cache命中率| 百分之 |表缓存命中率|
||Thread Cache命中率 |百分之 |线程缓存命中率|
|锁| 等待次数| 次| 锁等待次数|
||等待时间| 微秒 |锁等待时间|
2.标准
* SQL耗时越小越好，一般情况下微秒级别。
* 命中率越高越好，一般情况下不能低于95%。
* 锁等待次数越低越好，等待时间越短越好。
#### 前端指标
1.定义及解释
前端指标主要包括页面展示和网络所花的时间，具体如下：
| 一级指标 | 二级指标 |单位| 解释|
|---|---|---|---|
|页面展示| 首次显示时间 |毫秒| 在浏览器地址栏输入URL按回车到用户看到网页的第一个视觉标志为止。|
||OnLoad事件时间| 毫秒 |浏览器触发onLoad事件的时间，当原始文档和所有引用的内容完全下载后才会触发这个事件。|
||完全载入的时间| 毫秒| 所有onLoad JavaScript处理程序执行完毕，所有动态的或延迟加载的内容都通过这些处理程序触发的时间。|
|页面数量 |页面大小| KB |整个页面大小。|
||请求数量| 次 |从网站下载资源时所有网络请求的总数，尽量少。|
|网络 |DNS时间 |毫秒 |DNS查找时间。|
||连接时间 |毫秒 |连接时间就是浏览器与Web服务器建立TCP/IP连接的时间。|
||服务器时间| 毫秒| 服务器处理时间。|
||传输时间 |毫秒 |内容传输所用时间。|
||等待时间 |毫秒 |等待某个资源释放的时间。|
2.标准
* 页面要尽可能小及压缩。
* 页面展示和花费时间越短越好。
#### 稳定性指标
1.定义及解释
>最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。 一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于7×24运行的系统，至少应该能够保证系统稳定运行24小时以上。 如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险。
2.标准
* TPS曲线稳定，没有大幅度的波动。
* 各项资源指标没有泄露或异常情况。
#### 批量处理指标
1.定义及解释
>指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。处理效率是估算批量处理时间窗口最重要的计算指标。 关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。 长时间批量处理将会对联机在线实时交易产生重大的性能影响。
2.标准
* 在数据量很大的情况下，批处理时间窗口时间越短越好。
* 不能影响实时交易系统性能。
#### 可扩展性指标
1.定义及解释
>指应用软件或操作系统以集群方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/原始性能）/（增加资源/原始资源）×100%。 扩展能力应通过多轮测试获得扩展指标的变化趋势。 一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。
2.标准
* 理想的扩展能力是资源增加几倍，性能就提升几倍。
* 扩展能力至少在70%以上。
#### 可靠性指标
1.双机热备
对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：
* 节点切换是否成功及其消耗时间。
* 双机切换是否有业务中断。
* 节点回切是否成功及其耗时
* 双机回切是否有业务中断。
* 节点回切过程中的数据丢失量。在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。
2.集群
对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：
* 集群中某个节点出现故障时，系统是否有业务中断情况出现。
* 在集群中新增一个节点时，是否需要重启系统。
* 当故障节点恢复后，加入集群，是否需要重启系统。
* 当故障节点恢复后，加入集群，系统是否有业务中断情况出现。
* 节点切换需要多长时间。在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。
3.备份和恢复
本指标为了验证系统的备份、恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：
* 备份是否成功及其消耗时间。
* 备份是否使用脚本自动化完成。
* 恢复是否成功及其消耗时间。
* 恢复是否使用脚本自动化完成指标体系的运用原则。
* 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。
* 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。
* 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。
* 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。
* 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。
### 三、压测价值
1.压测流程
2.实现价值
可以快速定位瓶颈点：硬件、规格的瓶颈，中间件上的性能瓶颈、应用程序的瓶颈、操作系统上的瓶颈、网络设备上的瓶颈。
可以快速探测资源的状态：
比如CPU利用率高，看CPU消耗User、Sys、Wait哪种状态。
比如优化内存，给操作系统设置大量的cache，通过查看某个进程所占用的内存或者交换内存去分析问题。
比如磁盘IO，通过降低输出日志，异步或换速度快的硬盘来降低繁忙率。
比如网络IO，通过压缩减少内容大小、在本地设置缓存以及分多次传输等操作提高网络I/O性能。
比如内核参数，一般都有默认值，这些内核参数默认值对于一般系统没问题，但是对于压力测试来说，可能运行的参数将会超过内核参数，导致系统出现问题，可以用sysctl来查看及修改。
比如JVM主要分析GC/FULL GC是否频繁，以及垃圾回收的时间，可以用jstat命令来查看，对于每个代大小以及GC频繁，通过jmap将内存转储，再借助工具HeapAnalyzer来分析哪地方占用的内存较高以及是否有内存泄漏可能。
比如线程不够用，可以通过参数调整，增加线程；对于线程池中的线程设置比较大的情况，还是不够用可能的原因是：某个线程被阻塞来不及释放，可能在等锁、方法耗时较长、数据库等待时间很长等原因导致，需要进一步分析才能定位。
比如JDBC连接池不够用的情况下，可以通过参数进行调整增加；但是对于数据库本身处理很慢的情况下，调整没有多大的效果，需要查看数据库方面以及因代码导致连接未释放的原因。
3.性能调优
3.1调优步骤
确定问题
* 应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。
* 数据库配置：经常引起整个系统运行缓慢，一些诸如大型数据库都是需要DBA进行正确的参数调整才能投产的。
* 操作系统配置：不合理就可能引起系统瓶颈。
* 硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。
* 网络：网络负载过重导致网络冲突和网络延迟。
3.2分析问题
* 当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？
* 是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不同？
* 系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O情况如何？
* 问题是否集中在某一类模块中？
* 是客户端还是服务器出现问题？ 系统硬件配置是否够用？
* 实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？
通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。
3.3确定调整目标和解决方案
高系统吞吐量，缩短响应时间，更好地支持并发。
3.4测试解决方案
对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）。
3.5分析调优结果
系统调优是否达到或者超出了预定目标；系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题；调优是否可以结束了。 最后，如果达到了预期目标，调优工作可以先告一段落。
4.调优注意事项
* 在应用系统的设计开发过程中，应始终把性能放在考虑的范围内，将性能测试常态化，日常化的内网的性能测试+定期的真实环境的业务性能测试，PTS都可以支持。
* 确定清晰明确的性能目标是关键，进而将目标转化为PTS中的压测场景并设置好需要的目标量级，然后视情况选择并发、TPS模式，自动递增/手工调速的组合进行流量控制。
* 必须保证调优后的程序运行正确。
* 系统的性能更大程度上取决于良好的设计，调优技巧只是一个辅助手段。
* 调优过程是迭代渐进的过程，每一次调优的结果都要反馈到后续的代码开发中去。
* 性能调优不能以牺牲代码的可读性和可维护性为代价。
### 四、最佳实践
1.AB工具安装测试
```
leoheng@Leoheng-MBA ~ % yum -y install httpd-tools
leoheng@Leoheng-MBA ~ % ab -help
-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 指定接收到错误信息时不退出程序。
leoheng@Leoheng-MBA ~ % ab -c 100 -n 10000 https://www.123.com/
Server Software: nginx/1.10.2 (服务器软件名称及版本信息)
Server Hostname: 192.168.1.106(服务器主机名)
Server Port: 80 (服务器端口)
Document Path: /index1.html. (供测试的URL路径)
Document Length: 3721 bytes (供测试的URL返回的文档大小)
Concurrency Level: 1000 (并发数)
Time taken for tests: 2.327 seconds (压力测试消耗的总时间)
Complete requests: 5000 (的总次数)
Failed requests: 688 (失败的请求数)
Write errors: 0 (网络连接写入错误数)
Total transferred: 17402975 bytes (传输的总数据量)
HTML transferred: 16275725 bytes (HTML文档的总数据量)
Requests per second: 2148.98 [#/sec] (mean) (平均每秒的请求数) 这个是非常重要的参数数值，服务器的吞吐量
Time per request: 465.338 [ms] (mean) (所有并发用户(这里是1000)都请求一次的平均时间)
Time request: 0.247 [ms] (mean, across all concurrent requests) (单个用户请求一次的平均时间)
Transfer rate: 7304.41 [Kbytes/sec] received 每秒获取的数据长度 (传输速率，单位：KB/s)
...
Percentage of the requests served within a certain time (ms)
50% 347 ## 50%的请求在347ms内返回
66% 401 ## 60%的请求在401ms内返回
75% 431
80% 516
90% 600
95% 846
98% 1571
99% 1593
100% 1619 (longest request)
```
2.Jmeter工具安装测试
官网：https://jmeter.apache.org
备注：先安装jdk1.8
```
leoheng@Leoheng-MBA ~ % wget https://mirrors.tuna.tsinghua.edu.cn/apache//jmeter/source/apache-jmeter-5.1.1_src.tgz
leoheng@Leoheng-MBA ~ % tar -xf apache-jmeter-5.1.1_src.tgz
leoheng@Leoheng-MBA ~ % export JMETER_HOME=/usr/local/apache-jmeter-5.1.1/
leoheng@Leoheng-MBA ~ % export CLASSPATH=$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$JMETER_HOME/lib/logkit-2.0.jar:$CLASSPATH
leoheng@Leoheng-MBA ~ % export PATH=$JMETER_HOME/bin:$PATH:$HOME/bin
leoheng@Leoheng-MBA ~ % source /etc/profile
leoheng@Leoheng-MBA ~ % jmeter -v
leoheng@Leoheng-MBA ~ % jmeter -n -t test.jmx -l result.jtl -e -o /tmp/ResultReport
```
>-n: 非GUI模式执行JMeter
>-t: 执行测试文件所在的位
>-l: 指定生成测试结果的保存文件，.jtl文件格式
>-e: 测试结束后，生成测试报告
>-o: 指定测试报告的存放位置
>/tmp/ResultReport :手动创建的 ResultReport 报告文件夹的路径
3.Loadruner工具安装测试
```
准备：LoadRunner Generator11.0 for Linux.iso、centos7测试机
把iso上传到服务器上，然后mount -o loop LoadRunner Generator11.0 for Linux.iso /mnt 挂载到/mnt下。
leoheng@Leoheng-MBA ~ % yum install -y csh glibc.i686 zlib.i686 libstdc++.so.5 && yum provides libgcc_s.so.1 -y
leoheng@Leoheng-MBA ~ % useradd -g 0 -s /bin/csh lr_agent
lr_agent:x:1005:0::/home/lr_agent:/bin/csh
leoheng@Leoheng-MBA ~ % ./mnt/installer.sh
leoheng@Leoheng-MBA ~ % chown -R lr_agent:lr_agent /opt/HP
leoheng@Leoheng-MBA ~ % vim /home/lr_agent/.bash_profile
export PATH
export PRODUCT_DIR=/opt/HP/HP_LoadGenerator
export M_LROOT=$PRODUCT_DIR
export LD_LIBRARY_PATH=${M_LROOT}/bin
export PATH=${M_LROOT}/bin:$PATH
leoheng@Leoheng-MBA ~ % csh /etc/csh.cshrc
leoheng@Leoheng-MBA ~ % source /opt/HP/HP_LoadGenerator/env.csh
leoheng@Leoheng-MBA ~ % source /home/lr_agent/.bash_profile
leoheng@Leoheng-MBA ~ % source /etc/csh.cshrc
```
4.PTS工具测试
4.1.阿里云PTS控制台--》快速压测
4.2.查看压测报告
4.3压测流程概览图
