JMETER性能测试实践
一、Jmeter下载安装配置
https://blog.csdn.net/a13124837937/article/details/79628838
二、利用Jmeter进行诊断分析与调优
流程：
需求分析-->测试模型-->测试计划-->环境搭建-->脚本开发-->数据准备-->场景设计-->测试监控-->测试执行-->结果分析-->测试报告
性能测试：
性能测试为了暴露性能问题，评估系统性能趋势。性能测试工作实质上是利用工具去模拟大量用户操作来验证系统能够承受的负载情况，找出潜在的性能问题，分析并解决；找出系统性能变化趋势，为后续的扩展提供参考。
2.1 需求分析
性能测试需求分析要完成下面两项工作：
(1)采集性能测试需求：采集对象包括 业务交易、业务量、业务量趋势、用户信息、系统架构、业务指标、系统硬件指标等。
(2)分析性能测试需求：确定性能测试范围，分析出哪些业务纳入性能测试范围及性能指标是什么，另外要分析用户使用行为，业务分布，分析业务量；估算出 TPS 与并发用户数等性能测试执行依据。
性能测试指标分类：
(1)业务指标：TPS、RT(ART)、事务成功率等。
(2)硬件性能指标：CPU使用率、内存利用率、磁盘繁忙率等。
性能需求的主要采集内容：
（1）系统架构：物理架构与逻辑架构，包括中间件产品与配置、数据库配置，在测试环境搭建时需要参考
（2）采集业务并量化业务：在计算 TPS 及并发用户数时要用到。
（3）了解业务扩展趋势：比如业务年增长率?未来业务量？如需求要满足未来三年的业务增长需求，即3年后此系统的性能还要能够满足性能要求，在测试时就可能需要生成三年的存量业务数据。对于关系型数据库来说，数据量大时对性能的影响还是比较明显的。
（4）了解系统是否有归档机制？数据库中数据量大时对性能有影响，如果有归档机制，可以把一些无用或者过时的信息移到归档库中，这样就减少了当前库中的数据，有利于提高系统性能。
（5）采集业务发生时段：比如一天产生 20000订单，而高峰1小时就能完成 10000单，而不是平均到每小时。主要在估算 TPS 与并发用户数时用到。
（6）采集在线用户数，活动用户数，业务分布。有些系统用户量特别大，会对系统造成性能瓶颈，可以通过分析活动用户数和业务分布来分析负载情况。
（7）系统对第三方系统的依赖，在测试时要做mock，用程序代替第三方系统功能，不依赖与第三方系统。
（8）采集业务性能指标，比如响应时间、吞吐量（每秒支持多少业务）等。
（9）采集系统硬件指标，比如 CPU利用率、内存利用率或者可用内存等。
下图为一个业务需求采集示例表格：
2.1.1 需求采集
下面以JForum 论坛为例进行需求采集，首先要了解系统物理架构与逻辑架构。
物理架构：指导进行测试环境建立，测试环境与生产环境的架构趋于一致。
逻辑架构：让我们对系统的逻辑组成有所了解，进行测试时能够清楚地划分问题出现地区域。
2.1.1.1 系统架构
WebServer 负责反向代理，静态请求处理
Tomcat7 负载动态请求处理
Mysql5.6 做双击热备
为了更准确地模拟生产环境负载，在物理架构上尽量保持与生产同步，在机器配置及数量上，可以缩小比例，由测试环境来推算出生产环境的性能。
逻辑架构：逻辑架构展现的是软件系统中元件之间的关系，比如用户界面、数据库、外部系统结构等。下图是应用服务的逻辑结构，列出了系统服务组件、邮件服务、权限管理、业务服务（对于JForum 就是发帖、回帖、浏览帖子）。Web层是通过 JSP 与 Velocity Freemark 来展现的。
通过逻辑架构能迅速了解到系统的主要功能与服务，并且知道其逻辑关系，有助于我们设计测试场景。
2.1.1.2 业务流程
确定系统的主要业务流程，方便写性能测试用例。
需求文档中性能需求说明：
（1）此论坛为一个技术讨论性质的论坛，注册用户规模预计是10万，每日活跃用户数预计为5%，即5000.
（2）用户在论坛中的活动以浏览、发帖及回帖为主，日 PV 预计为 2 万 PV。其中浏览、发帖、回帖比例大约为 7:1:2.
PV：用户每访问一个页面统计为一个PV。
(3)系统业务增长率为 30%，系统在 3年内不打算进行分库分表处理，需要系统在性能上能够支撑住，也就是测试时需要3年的存量数据。
（4）要求系统能够提供良好的系统体验，比如浏览帖子、发帖、回帖应该控制在3秒内。
（5）为了系统稳定，要求在日常营运时 CPU 使用率<70%，磁盘 Disk ime<70%且无网络瓶颈。
Jforum业务量统计
2.1.1.3 硬件指标
系统硬件指标对象是硬件资源，比如CPU、内存、磁盘、网络带宽等。下表列出了主要的性能指标及阈值，这些指标比较抽象，在监控分析时应该进一步细化；比如 CPU的性能指标在 Linux 中分为用户利用率、系统利用率及平均负载等重要指标。
2.1.2 需求分析
需求分析的目的是确定性能测试范围，分析出哪些业务纳入性能测试范围及性能指标是什么？另外要分析用户使用行为、业务分布、分析业务量；估算出 TPS与并发用户数等性能测试执行依据。
2.1.2.1 圈定测试范围
如何圈定测试范围？
（1）确定高频次的业务
（2)确定性能影响大的业务
（3）确定此功能的可验证性。比如使用支付宝来支付商品费用，如果余额不足，会引导选择使用银行卡来支付。这样支付宝会调用银行的接口来完成银行账户的扣减。银行的接口不提供支持时，需要模拟银行网关这个过程，这就是可验证性分析及解决方案，最终采用 Mock程序来配合测试。
2.1.2.2 明确性能指标
（1）吞吐量（PV、TPS）：
日 PV 是 2 万，3年 30%的增长，日 PV=2*（1+30%）² ≈3.38万
（2）响应时间：要求3秒以内
（3） 成功率：99%以上
（4）稳定波动正常范围
（5）其他各项硬件等性能指标。参照硬件指标
2.1.2.3 分析业务量
测试数据的多少对测试结果会有影响，特别是数据成千万上亿条后，性能影响明显。
性能测试时，除了需要做足一定数量的历史数据，还得关注业务量的增长。需求中年业务增长率 30%，可以理解成年 PV 也会增加 30%。所以测试时要以第3年的业务量为标准来测试，避免错过积累一定数据后性能变差的情况，把问题提前暴露出来。
2.1.2.4 计算 TPS
TPS：表示每秒平均事务数。即吞吐量。
上面分析业务量的数据是以PV来统计的，要计算 TPS ，需要把 PV 转化成 TPS。一个 PV即是对服务器的一次请求，把一个请求放在一个事务中来统计服务器的响应耗时，响应完成即是一次事务完成，这么说一个 PV 即是一个事务（PV 并不能直接等同于 TPS，PV代表了一次客户请求，这次请求可能请求了很多信息，比如图片、样式、JS信息等，发新帖时我们通常只关心发帖的动作耗时，并不关心页面刷新时 JS、样式的耗时，此时就把 PV 等同于 TPS)；比如一个功能页面（浏览帖子）一秒会有 10 个 PV，那么此功能的 TPS 即为10。
TPS一般要取系统业务高峰期的值，虽然系统不是总处在高峰期，但高峰期 TPS 才能代表系统的实际处理能力。要得到高峰期的 TPS 我们需要分析业务发生时间。
UV：一天之内网站独立访客数（以 Cookie 为依据），一天内同一访客多次访问网站只计算 1 个访客（小于等于 PV）。
回到示例项目Jforum，找出日高峰。下表是高峰日 Jforum 论坛的 PV 数据统计（业务量单位为 PV）。
综合看上午十点是访问高峰，PV约为 5208（登录、浏览、回帖、发帖合计），那么这个时段 TPS=5208/3600≈1.45.
这样取平均值是不合适的，一个小时间隔时间太长，采集的业务数据并没有说明在这一个小时中吞吐量是平均的，还需要细分。如果能细分到每分钟的业务量数量，那 TPS 的估算就越准确。
可以采取 80/20 原则来估算，在性能测试中，20%的时间做了 80%的事情。
80/20 原则计算 TPS = 5208*80% / (3600*20%) ≈ 5.8 ，具体如下表
2.1.2.5 分析系统协议
分析完了上述内容，开始规划性能测试脚本的实现方式，一般性能测试的脚本可以采取录制或者手动开发的方式来完成。录制方式对协议的依赖性相当强，因为录制的方式多数是针对协议来开发的。
一般是先分析被测系统协议，再评估用什么辅助工具来完成。比如 http 协议用 Jmeter 进行录制，也可以手动开发。
用截包分析系统协议：常用的截包工具 Wireshark、Omnipeek、HttpWatch等。Wireshark 是使用最广泛的网络封包分析软件之一，支持市面上大多数协议（Http、Https、TCP、UDP等）。
Omnipeek 能够侦听多种网络通讯协议，执行管理、监控、分析、除错及最佳化的工作。
2.1.3 并发数计算
为什么要计算并发用户数？
性能测试的本质是模拟大量用户的负载来验证系统的性能，那模拟多少并发用户？计算并发用户数即是打算用多少模拟用户来代替实际用户数，是参照业务模型来计算的。
并发数的计算说到底还是一个估算，在性能测试执行时需要根据实际情况调整。衡量性能指标还是要参照 TPS 实际达到了多少，响应时间是多少，系统硬件（CPU、内存等）指标是否在限定范围内等要求。
常用的并发数计算方法有以下3种：
（1）由 TPS 来估算并发数
（2）由在线活动用户数来估算并发数
（3）根据经验来估算并发数
2.2 测试模型
业务模型：业务流程，业务系统在某个时间段内运行的业务种类及其业务占比，即哪些业务在哪个时间段在运行，业务量是多少。
测试模型：从业务模型中分析整理出来的进行测试的业务，通常是高频业务、高资源占用业务，这些业务需要具有可测性、可验证性。测试模型作为性能测试场景的依据，通常会继承业务模型大多数业务功能，有时也会因为特殊原因无法测试（比如第三方非开源加密程序，测试程序无法模拟），测试模型中将会去掉这部分业务，或者设计替代等价方案，比如第三方系统可以用 mock 程序实现。
性能测试场景：参照用户使用习惯设计负载场景，比如哪些业务的测试脚本一起运行，哪些业务有先后顺序，运行多少并发用户等。
Jforum的测试模型同上业务流程图
2.3 测试计划
测试计划考虑哪些内容？
（1）系统概述：简述系统使命、系统功能。
（2）测试环境：系统生产环境、测试环境、测试执行环境（就是测试负载机，我们这里是运行 JMeter 的机器）。
（3）需求分析：采集系统性能需求，确认性能测试需求范围。
（4）测试策略：表明此次性能测试我们将用什么样的手段来进行测试，比如采用 JMeter 来模拟用户大并发操作，对于第三方系统采用Mock程序。
（5）测试场景：如何组合业务场景进行性能测试。
（6）测试准备：测试前的环境准备，数据准备。
（7）时间计划：上面进行了需求分析、测试策略制订，就可以相对合理地估算测试资源及耗时，从而合理地安排测试工作。
（8）测试组织架构：测试相关人，明确不同人地工作职责。
（9）交付物清单：性能测试计划、性能测试报告、性能测试脚本等。
（10）系统风险：对测试过程中可能涉及的风险加以评估，确定风险应对策略。
