常用性能压测工具实战总结

一、压测背景

以前：未出社会之前经常用AB工具来压测自己的 nginx 欢迎页面，看着服务器的资源从20%到100%，发现原来一个开源的工具都可以把一台4C8G的虚拟机压爆满，然后就陷入沉思，低成本的压测都可以造成一台虚拟机的资源满负载，而且还是个静态页面，那如果发生在企业身上会如何？造成的损失远远高于压测方，后果不敢想象。

现在：我承认以前太天真了，既然有压测方，那肯定有防御方，遇到恶意压测他人网站的，直接通过各种全家桶拉黑、屏蔽掉就好了。那对于现在企业来说，各人觉得最大的价值就是探测资源性能、资源容量合理规划、增强业务稳定SLA、减少事故发生，这个对于测试还是运维来说都是天大的好事，也是价值的体现。

未来：压测的普适性，对企业带来的价值不止探测资源性能、资源容量合理规划，还有技术架构升级验证、业务系统上线测试、业务峰值稳定性测试等等，通过压测清楚资源的能力，降低盲目预估的风险，提高服务的可用性和稳定性。

1.所以为什么要做压测？

压测的目的就是通过压测(模拟真实用户的行为)，测算出机器的性能(单台机器的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。互联网电子商务：10000 TPS~1000000 TPS。互联网中型网站：1000 TPS~50000 TPS。互联网小型网站：500 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%、CPU sys%小于或者等于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压测流程概览图

原文链接