00 | 性能测试理论

性能测试概念

什么是性能：就是软件质量属性中的“效率”特性。

效率的特性：

时间特性：指系统处理用户请求的响应时间。
资源特性：指系统在运行过程中，系统资源的消耗情况。
- CPU 使用率
- 内存使用率
- 磁盘 I/O
- 网络带宽使用率
- ...

什么是性能测试？

性能测试是指通过自动化测试工具模拟正常、峰值以及异常的负载条件，来对系统的各项性能指标进行测试和评估的过程。

后台程序的处理性能（代码性能）
中间件、数据库、架构设计等是否存在瓶颈
服务器资源消耗（CPU、内存、磁盘、网络）
...

性能测试目的

评估当前系统能力。
- 例如：验收第三方提供的软件。
- 例如：获取关键的性能指标，与其他类似产品进行比较。
基于性能需求目标的测试验证。
精准容量规划，并验证系统容量的可扩展性。
- 根据各模块的承载量进行适当地收缩，来让出更多的可用资源

性能测试策略

主要分为：

基准测试
负载测试
稳定性测试
其他：并发测试、压力测试、容量测试等

基准测试

狭义：也就是单用户测试。在测试环境确定以后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标，以进行基础的数据采集。

如：一个用户迭代 100 次，关注响应时间（事务成功率需 100%）。

广义：是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。

如：先在 V1.0 版本的生产环境上进行性能测试收集所有的性能指标作为基准测试。
再在 V1.1 的开发版本上，使用与 V1.0 基准测试时相同的环境、配置、用户量等进行性能测试，再收集性能指标。
查看 V1.1 版本的性能是否比 V1.0 有所提升。

基准测试数据的用途：

为多用户并发测试和综合场景测试等性能分析提供参考依据。
识别系统或环境的配置变更对性能响应带来的影响。
为系统优化前后的性能提升/下降提供参考指标。

负载测试

含义：负载测试是指获取各个事务在不同负载条件下的性能表现。通过逐步增加系统负载量，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。

负载：指向服务器发送的请求数量。请求越多，负载越高。
负载测试关注的重点是逐步增加压力。如：分别用 10、20、30、...个并发用户跑 10 分钟。
通过负载测试，一般能找到系统的最优负载和最大负载。

示例：健身举哑铃

10斤哑铃，举起10个，需要15s
20斤哑铃，举起10个，需要15s
30斤哑铃，举起10个，需要15s —— 最优负载
40斤哑铃，举起10个，需要20s —— 最优负载
50斤哑铃，举起10个，需要40s
60斤哑铃，举起10个，需要100s —— 最大负载
70斤哑铃，举不起来

稳定性测试

含义：稳定性测试是指在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试，并最终保证服务器能满足线上业务需求。时长一般为一天、一周等。

其他类型

并发测试

广义：在极短的时间内发送多个请求，来验证服务器对并发的处理能力。如：抢红包、抢购、秒杀活动等。
狭义：模拟多用户在同一时间访问同一应用（进行同一具体操作）的测试，用于发现并发问题，例如线程锁、资源争用、数据库死锁等。

容量测试

关注软件在极限压力下的各个参数值。例如：最大 TPS、最大连接数、最大并发数、最大数据条数等。

压力测试

压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。

压力测试分为高负载下的长时间（如 24 小时以上）的稳定性压力测试，和极限负载情况下导致系统崩溃的破坏性压力测试。

稳定性压力测试：在系统高负载的情况下（下图中接近 C 点），长时间运行（24 小时），查看系统的处理能力。
破坏性压力测试：在系统极限负载的情况下（下图中 C-D 点），对系统进行压力测试，查看系统容错能力和错误恢复能力。

性能测试指标

性能指标：在性能测试的过程中，记录一系列的测试数据值，用这些实际记录的数据值与需求中的性能要求做对比，达标则表示性能测试通过；未达标则可能是性能 Bug。

不同人群关注的性能指标各有侧重。前台服务接口的调用者一般只关心吞吐量、响应时间等外部指标。后台服务的所有者则不仅仅关注外部指标，还会关注 CPU、内存、负载等内部指标。

拿某打车平台来说，用户所关心的是智能提示服务的外部指标能不能抗住因大波优惠所导致的流量激增；而对于智能提示服务的开发、运维、测试人员，不仅仅关注外部指标，还会关注 CPU、内存、IO 等内部指标，以及部署方式、服务器软硬件配置等运维相关事项。

常见的性能指标：响应时间、并发数、吞吐量、错误率、点击数、PV/UV、系统资源利用率等。

3 个关键的业务指标：
- 响应时间
- 并发数
- TPS/QPS（吞吐量）
系统资源指标：
- CPU
- 内存
- 磁盘 I/O
- 网络带宽使用率

响应时间

含义：系统处理一个请求或一个事务的耗时（客户端从发起请求到获取响应）。

响应时间是终端用户对系统性能的最直观印象，包括了系统响应时间和前端展现时间。

系统响应时间：反应的是系统能力，又可以进一步细分为应用系统处理时间、数据库处理时间和网络传输时间等。
前端展现时间：取决于客户端收到服务器返回的数据后渲染页面所消耗的时间。

因此，性能测试又分为后端（服务器端）的性能测试和前端（通常是浏览器端）的性能测试。

系统响应时间 = 应用程序处理时间（A1+A2+A3） + 网络传输时间（N1+N2+N3+N4）

响应时间的指标取决于具体的服务类型。

如智能提示一类的服务，返回的数据有效周期短（用户多输入一个字母就需要重新请求），且对实时性要求比较高，则响应时间的上限一般在 100ms 以内。
而导航一类的服务，由于返回结果的使用周期比较长（整个导航过程中），响应时间的上限一般在 2-5s。

对于响应时间的统计，应从均值、.90、.99 等多个分布的角度统计，而不仅仅是给出均值。

50 th(60/70/80/90/95 th)：如果把响应时间从小到大顺序排序，那么 50％的请求的响应时间在这个范围之内。后面的 60/70/80/90/95 th 也是同样的含义。

常见瓶颈：同一请求/事务的响应时间忽大忽小。

在正常吞吐量下发生此问题，可能的原因有两方面：

服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁。
硬件服务器本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。

并发数

含义：在同一时刻与服务器正常进行交互的用户数量。

系统用户数：系统注册的总用户数。
在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。
并发用户数：某一物理时刻同时向系统提交请求的用户数。

吞吐量

含义：吞吐量（Throughput）是指在单位时间内，系统处理客户端请求的数量。

吞吐量 = 并发数 / 响应时间

从不同维度来描述：

“Bytes/Second”和“Pages/Second”表示的吞吐量，主要受网络设置、服务器架构、应用服务器制约。
“Requests/Second”和“Transactions/Second”表示的吞吐量，主要受应用服务器和应用本身实现的制约。

吞吐量是衡量服务器性能好坏的直接指标，通常表现如下：

在系统处于轻压力区（未饱和）时，并发用户数上升，平均响应时间（基本不变），系统吞吐量（上升）。
在系统处于重压力区（基本饱和）时，并发用户数上升，平均响应时间（上升），系统吞吐量（基本不变）。
在系统处于崩溃区（压力过载）时，并发用户数上升，平均响应时间（上升），系统吞吐量（下降）。

QPS

含义：服务器每秒钟处理的接口请求数量（一个服务器中有多个接口，QPS 指的是所有接口在同一个单位时间内的被处理数量之和）。

TPS

含义：服务器每秒钟处理的事务请求数量。

一个事务通常指的是界面上的一个业务场景操作。一个事务可以包含一个或者多个接口请求。

一个业务请求发送给服务器后，最终会定位到服务器对应的业务请求的代码，既有可能是一段代码也有可能是多段代码。

示例：

登录操作：发送一个登录请求 —— 则登录事务对应 1 个接口请求
支付操作：查询用户余额请求 + 支付安全校验请求 + 支付请求 —— 则支付事务对应 3 个接口请求

结论：

对于登录事务而言，当 TPS 为 10 时，服务器的 QPS 也是 10。
对于支付事务而言，当 TPS 为 10 时，服务器的 QPS 就是 30。

吞吐量计算方法

1）均值计算

TPS = 总的请求数 / 总的时间

问题：对于同一天的时间内，不同的时间段，请求速率会有波动，这样计算会被平均掉，法测试负载高的情况。

2）二八原则

含义：80% 的请求数会集中在 20% 的时间内完成。

TPS = 总的请求数 * 80% / 总的时间 * 20%

通常二八原则的计算方法会比平均的计算方式更具代表性和准确。

3）按照每天的具体业务数据进行计算（稳定性测试 TPS）

当获取每天的具体业务统计数据时，就可以统计出业务请求集中的时间段作为有效业务时间；并统计有效业务时间内的总请求数

TPS = 有效业务时间的总请求数 * 80% / 有效业务时间 * 20%

4）模拟用户峰值业务操作的并发量：（压力测试 TPS）

获取每天的交易峰值的时间段，及这个时间段内的所有请求的数量。

TPS = 峰值时间内的请求数 / 峰值时间段 * 系数（倍数）

系数可以是 2、3、6、10，根据要达成的性能指标而定。

案例

某购物商城，经过运营统计，正常一天成交额为 100 亿，客单价平均为 300 元，交易时间主要为 10:00-14:00 以及 17:00-24:00，其中 19:00-20:00 的成交量最大，大约成交 20 亿。

现升级系统，需要进行性能测试，保证软件在上线后能稳定运行。

请计算出系统稳定性测试时的并发（负载）量，及保证系统峰值业务时的并发（负载）量。

稳定性分析

有效的交易时间为 10:00-14:00、17:00-24:00，一共为 7 个小时
有效的请求数：100e / 300
稳定性 TPS = 100e / 300 * 80% / (7 * 3600 * 20%)

压力分析

峰值的交易时间为 19:00-20:00，一共为 1 个小时
有效的请求数：20e / 300
峰值 TPS = 20e / 300 / 3600 * 系数

系统资源利用率

含义：指系统各种资源的使用情况。一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。

建议：没有特殊需求时，通常要求如下：

CPU 不高于 80%(±5)
内存不高于 80%
磁盘不高于 90%
网络不高于 80%

其他指标

点击数

点击数是衡量 Web 服务器处理能力的一个重要指标。

点击数不是通常一般人认为的访问一个页面就是１次点击数，而是指该页面包含的元素（图片、链接、框架等）向 Web 服务器发出的请求数量。
通常我们也用每秒点击次数（Hits per Second）指标来衡量 Web 服务器的处理能力。
注意：只有 Web 项目才有此指标。

错误率

含义：指系统在负载情况下，失败业务（取决于断言结果）的占比。

错误率＝(失败业务数/业务总数)*100%

不同系统对错误率要求不同，但一般不超过千分之五。
稳定性较好的系统，其错误率应该由超时引起，即为超时率。

01 | 性能需求分析

性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果。

性能需求分析通常包含的内容如下：

熟悉被测系统
- 熟悉系统的业务功能
- 熟悉系统的技术架构
确定性能测试指标
- 有需求：按照需求进行测试
- 没有需求：查找相关资料、与同类型软件对比、对未来数据进行预估等
明确性能测试内容
- 从业务角度，挑选核心业务进行测试
- 从技术角度，挑选逻辑复杂度高、数据量大的业务进行测试
确定性能测试策略
- 负载测试、稳定性测试等

测试指标

性能测试指标要可测量，如定量指标给出具体数值，定性指标要给出具体描述。

吞吐量（TPS/QPS）
事务响应时间
用户并发数
数据库的数据量
系统的稳定运行时间要求
是否需要考虑系统支持水平扩展
考虑系统的最大容量

性能测试指标的来源一般如下：

1）需求文档

客户明确需求：通常情况，客户有明确的需求，提出一些性能测试指标。例如：每秒登录用户量多少，用户在线总量多少等。
客户隐形需求：基于客户明确指标下，会有一些隐性指标，例：100 万在线用户的查询在 5 秒响应，我们也许纳入性能测试指标内。
用户模型确定：有了上述性能测试指标后，就可以创建我们的用户模型了。如下：
- 用户指标：用户登录 TPS 需达到 50；
- 用户总量：总用户量 100 万；
- 用户模型：系统每天用户在线量在 100 万左右，平均在早晨 08:00-11:00 期间登录，其中登录与查询的比例为 1:5。

2）运营数据

根据历史运营数据收集、分析业务数据，如：

注册用户数、日活、月活等？计算用户的增长速度
每月、每周、每天的峰值业务量是多少？
用户频繁使用的功能模块、业务场景是哪些？

测试内容

测试范围

哪些接口要进行性能测试和稳定性测试。
哪些页面业务逻辑要进行性能测试和稳定性测试。

关注重点

针对新增或重构模块：进行全面的测试，优先覆盖典型场景。典型场景如下示例：
- 核心业务功能
- 用户频繁使用的业务功能
- 特殊交易日或峰值交易的业务功能
- 发生过性能问题的业务功能
- 资源占用高的业务功能
- 代码优化过的业务功能
- ...
针对继承模块：进行回归验证即可，不做探索性的性能测试。

测试策略

分析步骤：

根据上述性能测试内容的提取方法，整理出需要进行性能测试的测试点。
根据性能指标计算方法，得到每个测试点要满足的性能。

案例：

针对每个核心的业务功能（接口）都要达到对应的性能指标要求。
基于业务流程（多个接口的组合）来测试是否达到性能指标的要求。
模拟用户真实的业务场景，进行长时间的稳定性测试。

期望的 TPS 和最大响应时间，如下：

02 | 性能测试计划

在实际工作中，通常有性能测试的计划模板，对照模板进行编写即可。

通常包含内容如下：

测试背景 —— 背景介绍
测试目的 —— 需求分析阶段确定的项目需要达成的性能目标
测试范围 —— 需求分析阶段确定的性能测试点
测试策略 —— 结合前面的测试范围，考虑使用什么样的方式来进行性能测试，可以达成对应的测试目标
风险控制 —— 管理型分析（从技术、人员、时间、进度各个方面考虑可能会出现的问题及如何解决这些问题）
进度与分工 —— 说明性能测试工作要分为哪几个步骤进行，每个步骤的开始/结束时间，及对应的负责人
交付清单 —— 对应进度安排中每个阶段的阶段产物

案例如下：

1）测试背景

轻商城是公司新开发的一个电商项目，为了保证项目上线后能够稳定的运行，且在后期推广中能够承受用户的增长，需要对项目进行性能测试。

2）测试目的

对新电商项目进行性能测试的核心目的包括：

确定核心业务功能的 TPS。
对业务流程（多接口组合）进行压测。
系统能在实际系统运行压力的情况下，稳定的运行 24 小时。

3）测试范围

通过对性能测试需求的调研和分析，确定被测系统的测试范围如下：

4）测试策略

1. 基准测试

先做基准测试，确定估算的标准。

2. 负载测试

通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试。
分别模拟 5、10、30、50、100 个用户对系统进行负载测试，查看不同并发时系统软件各项指标是否符合需求。

3. 稳定性测试

用 200 个用户对系统进行 7*24 小时不间断的稳定性测试，验证系统在长时间的正常负载下的表现是否正常。
- 是否发生内存、句柄、连接等泄露；
- 是否正常触发 fullgc（JVM 调优就是为了减少 fullgc 频率）；
- 数据库的容量问题；
- ...

5）风险控制

风险类型	风险描述	风险级别	应对方案
环境风险	找不到合适的软硬件等资源	高	测试前期阶段识别，并使用相近配置进行验证，后期需在测试报告中提出
环境风险	部署出现问题，联调进度缓慢	高	更换环境；增加资源配置
人力风险	测试周期紧张，需要多名测试人员同时进行测试，但具备性能测试能力的人员不足	高	延长测试周期，或在前期培训相应人员
数据风险	构造测试数据时间较长	高	开发人员协助
交付风险	发现比较严重的 Bug	高	延长测试时间，增加对应人员

6）交付清单

性能测试计划、性能测试脚本、性能缺陷统计和性能测试报告等。

7）进度与分工

03 | 性能测试用例设计

可参考如下性能测试用例的模板来编写：

对于单个业务功能（接口）的性能测试，每个测试点编写一个测试用例（如果多个接口有强关联，可以将多个接口放入同一个用例）。
对于多个业务功能的组合测试，需按照用户实际的业务场景，挑选出有代表性的业务流程编写测试用例。

04 | 性能测试脚本开发

示例：使用 JMeter 编写测试脚本并调试，常用测试元件如下：

取样器 —— HTTP 请求
配置元件 —— HTTP 请求默认值
配置元件 —— 用户定义的变量
后置处理器 —— JSON 提取器
断言 —— 响应断言
断言 —— JSON 断言
监听器 —— 察看结果树
监听器 —— 聚合报告

基础结构如下：

Jmeter 详细使用说明可参见系列博文《https://i.cnblogs.com/posts?cateId=1938518》

05 | 性能测试资源准备

测试环境

在进行性能则试之前，需要先完成性能测试环境的搭建工作，测试环境一般包括硬件环境、软件环境及网络环境。

性能测试环境的特点

性能测试对测试环境的独立性要求更高，更为严格。
如果某环境下运行多个系统，就很难判断其中的某个环境对资源的占用情况。

尽量保持性能测试环境与真实生产环境的一致性

硬件环境
- 包括服务器环境、网络环境等
软件环境
- 版本一致性：包括操作系统、数据库、被测应用程序、第三方软件等
- 配置一致性：包括操作系统、数据库、被测应用程序、第三方软件等
使用场景的一致性
- 基础业务数据的一致性：尽量模拟真实场景下的业务数据使用情况
- 业务操作模式的一致性：尽量模拟真实场景下用户的业务功能使用情况

性能测试环境的建模

主要分为网络拓扑图、硬件、软件、参数配置、测试数据等。描述清楚几个要点：

有几台测试服务器？
每台服务都有什么服务？（前台 Web 服务、Redis、数据库等）
各服务器间的连接关系？

建模思路

分析系统真实运行的网络拓扑环境；
明确公司可对性能测试进行投入的软硬件资源；
最好的性能测试环境就是待发布的生产环境；
次好的性能测试环境就是 1:1 复制的生产环境；
对于软硬件资源不足情况下，同比例缩小系统每一层结构中的机器数量。注意：系统中的每一层必须要有机器（至少可验证分库、分布式的处理正确性）；
测试环境的搭建最好让运维人员负责，即使硬件不同，但在软件版本和配置上也可以尽可能跟生产环境保持一致。

思考：低配测试环境的性能测试意义

即使测试环境较 low，但性能测试还是能起到意义的，至少能够：

验证业务流程的处理正确性。
验证程序没有明显的性能问题。
验证单台机器的处理能力。

测试数据

构造方法：

压测环境中的数据量尽量与生产环境中的数据量一致。为了快速创建大量数据，通常使用如下方法：

通过接口构造
通过数据库构造

数据量：

数据库中该有多少测试数据才是合理的呢？

需要考虑、中长期系统运营的数据出现的可能性
和性能测试干系人讨论，讨论得出数据
需要考虑数据库配置文件、缓存参数的设置情况
明确 Cache 预 load 的数据说明

缓存数据：

业务正确性：如 HTTP 请求中的 cookies 贯穿整个业务交互过程，在测试脚本中应该缓存 cookies，保证业务正常，同时考虑后台对 cookies 的存取方式，保证大并发下不会出现 cookies 丢失或者写满的情况。
性能表现：关注冷启动和热启动这两种场景下的性能表现。
- 现象：
  - 很多时候，在我们搭建完性能测试的基准环境，开始执行性能基准测试的时候，往往会发现系统刚开始运行时业务处理的响应时间都会相对比较长，只有当性能测试执行了一段时间后，系统的各项指标以及事务的响应时间才逐渐趋于正常。
  - 另外，在做前端性能测试的时候，我们对于一个页面的打开时间通常会去统计两个指标，一个是首次打开时间，另一个是多次打开的时间。而且，通常来讲首次打开时间会远大于后面再次打开的时间。
- 原因：
  - 服务器端会对“热点”数据进行缓存，而不是每次访问都直接从数据库中获取数据。那么，系统刚开始运行时，由于没有任何之前的访问记录，所有数据都需要访问数据库，所以前期的事务响应时间都会比较长。但是，随着缓存的建立，后续的访问就会比较快了。这个前期对系统的“预热”过程其实是在“预热”缓存。
  - 浏览器端也会缓存从服务器端拿到的各种静态资源，在第一次访问时这些资源都需要从服务器端获取，而后面再访问时，这些静态资源已经在浏览器的缓存中了，所以访问速度会大大加快。

为此，在做性能基准测试的时候，有经验的工程师通常都会先用性能场景对系统进行一下“预热”，然后再真正开始测试。

测试工具和监控工具

Loadrunner
Jmeter
Siege
Apache Bench
自写工具

测试桩

测试桩作用：用于性能瓶颈定位时，规避测试中一些非主要的流程，通常由研发人员提供。

模块之间的测试桩：流程中包含 AB 模块，性能定位 AB 模块性能瓶颈时，需在 AB 模块之间做桩，让其支持单压 A，或者单压 B 模块。
辅助测试桩：测试流程中的一些非主要流程，且测试脚本不易实现。例：登录时安全校验输入验证，可适当地让研发人员进行前段安全校验的屏蔽。

06 | 性能测试脚本执行

先保证脚本调试通过之后，才能进入正式压测阶段。

正式执行性能测试前，需要根据要模拟的业务负载量来选择适当的测试机。

压测机

通常会选择 Windows 或者 Linux 环境来执行脚本：

Windows 环境：操作界面化、直观、易上手，但是软件占用机器资源较多，导致资源可使用率不高，降低了可支持并发数。
Linux 环境：命令行操作，结果查看不太方便，但资源可使用率相对较高，可支持较高并发。

分布式执行

如果单台压测机的并发量不能够满足负载要求，则可以通过分布式压测来提高并发量。如 JMeter 工具支持分布式压测，即多台机器同时执行同一个脚本，然后统计结果。

注意事项

性能测试环境一定要是干净的：后台服务器除了自己没有其他人在用；测试元素不能有其他；本机一切影响网络的都要关掉。
如果是在生产环境压测，则注意是否有脏数据，以及测试后的数据清理机制。
最好每轮性能测试都重启机器，这样垃圾回收和缓存的影响能降到最小。

07 | 性能测试监控

监控指标

业务指标：并发数、响应时间、吞吐量等
系统资源指标：
- CPU：CPU 使用率、CPU 使用类型（用户态、内核态）
- 内存利用率：实际内存、虚拟内存
- 磁盘：I/O 速度、磁盘等待队列
- 网络：带宽使用率
Java 应用：JVM 监控、JVM 内存（堆区）、Full GC 频率等
数据库：慢查询、连接数、锁、缓存命中率
压测机资源：CPU 使用率、内存使用率、磁盘空间使用率（测试日志的产生）、网络带宽使用率

一般情况下，测试人员只需要关注 1、2、5，来判断系统是否存在性能问题。

而开发人员要定位性能问题时，一般会再次复现场景，并监控所有的性能指标，来进行分析并调优。

监控工具

要对性能测试指标进行监控，可以使用系统自带的监控工具，也可以使用第三方监控工具或者监控平台。

业务指标
- 通过性能测试工具（如 LoadRunner、JMeter 等）以图形化方式监控。
系统资源指标
- 使用 Jmeter 插件 PerfMon 进行服务器的系统资源监控。
- 使用 Linux 命令监控：top、free、vmstat、sar、iostat 等。
- 使用 Nmon 工具：全面监控 linux 系统资源使用情况，包括 CPU、内存、I/O 等，可独立于应用进行监控。
Java 应用
- jvisualvm
数据库
- SQL 查询
- SQL 日志
压测机资源
- Windows 自带“任务管理器”
- Linux 命令

使用 Jmeter 客户端监控业务及系统资源指标

如使用 JMeter“聚合报告”组件监控业务指标。
如使用 JMeter 性能监控插件“PerfMon Metrics Collector”监控服务器资源指标。

使用 nmon 监控系统资源指标

nmon 是一款快速获取 linux 系统资源的小工具。

下载与安装

下载 rpm 包：http://mirror.ghettoforge.org/distributions/gf/el/6/gf/x86_64/nmon-14i-1.gf.el6.x86_64.rpm
安装 rpm 包：rpm -ivh nmon-14i-1.gf.el6.x86_64.rpm
执行 ./nmon 即可运行

前台运行使用

键入“c”查看系统 CPU 使用情况：

键入“m”查看系统内存使用情况：

键入“n”查看网络使用情况使用情况：

JVM 监控

JVM dump

很多情况下，都会出现 dump 这个字眼，jvm 中也不例外，其中主要包括内存 dump、线程 dump。

首先，内存dump是指通过 jmap -dump <pid> 输出的文件，而线程 dump 是指通过 jstack <pid> 输出的信息。

当发现应用内存溢出或长时间使用内存很高的情况下，通过内存 dump 进行分析可找到原因。
当发现 cpu 使用率很高时，通过线程 dump 定位具体哪个线程在做哪个工作占用了过多的资源。

获取及分析方法详见《性能测试瓶颈调优》JVM dump 内容部分。

jvisualvm

使用本地 jvisualvm 远程监控服务器的步骤如下：

修改 Tomcat 的启动脚本（catalina.sh 或 catalina.bat），并启动 Tomcat 服务。

-Dcom.sun.management.jmxremote
-Djava.rmi.server.hostname=182.92.91.137
-Dcom.sun.management.jmxremote.port=10086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

进入本地 jdk 安装目录的 bin 目录，找到 jvisualvm.exe 并启动。
右键“远程”选择“添加远程主机”，并输入步骤 1 配置的远程服务器 IP。

点击刚刚添加的主机，右键点击“添加JMX连接”，填写端口号（步骤 1 配置的端口号）。

点击 JMX 连接，选择监控，看 JVM 对应的监控指标。（重点关注：CPU 使用、堆的内存使用）

08 | 性能测试瓶颈调优

性能调优的步骤：

确定问题：根据性能监控的数据和性能分析的结果，确定性能存在的问题。
确定原因：确定问题之后，对问题进行分析，找出问题的原因。
确定解决方案（改服务器参数配置/增加硬件资源配置/修改代码）。
验证解决方案，分析调优结果。

注意：性能测试调优并不是一次完成的过程，针对同一个性能问题，上面的步骤可能要经过多次循环才能最终完成性能调优的目标（即：测试发现问题 -> 找原因 -> 调整 -> 验证 -> 分析 -> 再测试 ...）

具体的性能瓶颈调优分析可参考《性能测试瓶颈调优》。

09 | 输出性能测试报告

按照测试报告模板来进行编写。通常包含内容如下：

测试目标
测试结论（通过/不通过）
性能测试的过程记录：如测试范围、指标数据、发现的问题、调优结果等
性能测试过程中的风险，当前是否还存在风险
本次性能测试的复盘总结

性能测试流程/设计