JMeter性能测试

性能测试前言

老师开局一句话：性能测试和你会不会JMeter一点关系没有……

作者坚持技多不压身的原则，还是多学一点JMeter吧，看老师到底要怎么讲下去，什么并发量、吞吐量啥的……

性能测试的核心思想：在于创造大量并发去访问接口，检查当前接口在极端情况下会出现的问题。

比如访问的人数越多，内存会不会小？CPU会不会高？网络带宽会不会大？这三种指标只要有一项过高，就很有可能会牵连其他两项升高，最终导致服务器停滞。

JMeter创造并发的手段很多很全面（所以性能测试还是可以用到JMeter的，可能老师觉得思想和知识积累才是性能测试最重要的东西吧，要知道核心特征的值对应着什么样的性能……），有丰富的插件，可以对各种场景进行模拟。

怎样学习性能测试：

1.首先明确吞吐量QPS/TPS（系统在单位时间内处理的请求/事务数量）、并发量、响应时间等核心性能指标；

2.再在实际项目中进行监控/报警，保证服务器维持一个较为稳定的状态，或者能够及时重启服务器把损失降到最低；

3.然后，涉及到软件工程所讲的性能需求分析，怎么压怎么测试要写一个性能测试报告，这是最为重要的一点；

4.最后专家能力：能够及时分析性能瓶颈，跟开发人员提出优化建议。

性能核心概念

下面是一些基本概念的解释和如何利用这些概念来判断性能，图片来自于黑马课程【3天带你搞定Jmeter性能测试！2023新版！全面详细，快速上手！-黑马程序员武汉中心】 https://www.bilibili.com/video/BV12W4y197qU/?p=6&share_source=copy_web&vd_source=3026e1149e1e36cc45042854c30dd20c

1. 吞吐量 (QPS/TPS)

定义: QPS(Queries Per Second) 是每秒查询率，TPS(Transactions Per Second) 是每秒事务数。它们衡量了系统每秒钟能够处理的请求数或事务数。QPS适用于没有写入操作的场景，TPS适用于写入操作的场景。
应用: 通过分析系统的QPS/TPS，可以评估系统能够处理的并发负载量。如果QPS/TPS太低，可能表示系统无法高效处理请求。

如何优化:优化代码和数据库查询、提升服务器硬件性能、使用负载均衡（作者在Redis中有介绍过）和分布式系统架构。

这里的RPS和TPS是一样的。完成一个支付操作就相当于一个事务，而一个事务可以包含多个查询操作。

2. 并发量

定义: 并发量指的是系统能够同时处理的用户数量或请求数量。
应用: 测量并监控并发量可以帮助确定系统是否能够在高负载下稳定运行。
注意，如果涉及到庞大数据并发，则建议分布式测试并发量。在JMeter中，只要用户数达到上万，个人PC肯定死机，服务器也不可能搞得太多，所以要分担这样的测试。比如10w并发，可以分成20台机器，每台进行5k并发。

3. 响应时间

定义: 响应时间是系统从接收到请求到生成响应所花费的时间。是用户能够直接感受到的，其他的吞吐量啊并发量啊用户都无法直观感受。
应用: 如果响应时间太长，用户可能会对网站或应用感到不满。

响应时间一共分为两种，一种是服务器处理数据（HTTP请求、数据库数据、请求返回值）的处理时间，一种是请求或响应的网络传输时间。

1. 分段指标（Percentile Metrics）

在性能测试中，我们通常不仅关注平均响应时间，还要关注分段指标。分段指标可以帮助我们更全面地了解系统的性能表现。

定义:
分段指标（例如90th percentile, 95th percentile, 99th percentile）表示在所有请求中，有X%的请求的响应时间低于或等于这个指标。例如，如果99th percentile的响应时间是2秒，这意味着99%的请求的响应时间都在2秒以下。
为什么重要:
分段指标可以帮助我们发现系统中的性能瓶颈。
平均响应时间可能隐藏了一些重要的信息，例如少量的非常慢的请求，而分段指标可以帮助揭示这些信息。

2. 九五线（95th Percentile）

九五线或者95th percentile是一种特定的分段指标。

定义:

95th percentile表示在所有请求中，95%的请求的响应时间都低于或等于这个值。它是性能测试报告中的一个关键指标，用来评估系统的性能。

为什么重要:

它帮助我们理解系统在大多数情况下的表现。
如果95th percentile的响应时间是可接受的，这意味着大多数用户将会体验到良好的性能。

4.错误率

注意错误率一定是在负载情况下业务失败的概率，并发数一定要超过一定的数量。
问题诊断: 一个突然增加的错误率可能指示了系统中的一个问题，例如数据库连接丢失、服务瓶颈或其他问题。
SLA遵守：对于许多系统，特别是商业系统，可能会有一个服务级别协议（SLA），它规定了最大的可接受错误率。
用户体验：高错误率直接影响用户的体验和满意度。

5.资源使用率

性能瓶颈识别：通过观察哪个资源的使用率达到或接近100%，可以帮助识别系统中的性能瓶颈。
成本效益：通过了解资源使用率，组织可以决定是否需要购买更多的硬件资源或者是否可以节省资源。
预测：通过监控资源使用率的趋势，可以预测将来何时可能会出现资源短缺，从而及时进行规划和调整。
SLA遵守：与错误率相似，对于某些系统，可能会有SLA规定资源使用率的上限，超出这个上限可能会导致合同违约。

提取性能指标

提取性能指标是为了明确地定义什么是"好的"或"可接受的"性能。明确性能指标可以帮助团队集中精力，提高系统性能，并提供更好的用户体验。以下是三种常用的方法，用于确定这些指标：

1. 直接给出需求

这种方法通常基于业务需求或合同中的服务级别协议（SLA）。

详细介绍：

基于业务：某些业务领域可能对响应时间、可用性或其他性能指标有明确的预期。例如，金融交易平台可能需要在特定的毫秒内完成交易。

合同或SLA：与外部客户的合同中可能会明确写出性能指标，违反这些指标可能会导致经济损失或法律责任。

管理期望：有时，高级管理层可能会基于他们的经验和期望设定性能指标。

2. 历史运营数据分析（重点）

分析过去的性能数据可以为将来提供有价值的见解。

详细介绍：

性能基线：通过对系统在正常运营条件下的性能数据进行分析，可以建立一个性能基线。

趋势分析：通过长时间的监控和数据收集，可以识别性能的趋势。例如，如果每个月的响应时间都在增加，那么可能需要采取行动。

异常识别：历史数据可以帮助识别和理解异常性能事件，比如为什么在某一天系统的响应时间突然增加。

日常性能指标计算

PV可以认为是请求量，也就是实际业务量。我们可以根据实际业务量（以4.13万为例），应用二八原则计算性能指标：

因为业务不是时时刻刻都有那么多人的，只是集中在某些时间段产生。所以，也可以利用有效工作时长下的订单总数计算指标：

都是同一个运营数据，一个按天进行计算，一个按小时进行计算，方法都是正确的，当然选后者更为精确。因为前者默认将所有时间包括空闲时间都作为请求分担者，可能会导致白天（请求多的时候）性能不够的情况。

峰值性能指标计算

系数：用于预估将来的峰值变化，系数为n表示预测将来请求数量会达到当前请求的n倍。计算得到吞吐量后，根据经验或实际感受给定响应时间的合理范围。

示例：电商项目性能需求

1.vu可以理解为：这个系统一天需要处理的登录请求。专业术语，可以用于个人网站的性能需求展示。

2.与上个版本保持一致：获取上个版本的已知性能作为基准，让当前项目通过这个基准，这就是下文所讲的基准测试。

3.活动当天访问量对应负载测试，整点抢购对应负载测试或压力测试，稳定运行对应稳定性测试。这些测试在下文中都有介绍。

读者可能会想：整点抢购是否应该使用并发测试？

其实，“整点抢购”确实与并发用户有关，这种情况下的测试常被称为并发测试，但实际上，它更类似于一个特定的负载测试或压力测试场景，这取决于测试的负载是否超出了正常预期。模拟的用户数量、频率和行为模式将决定这是负载测试还是压力测试。

负载测试：通常会设定一个预期的负载，例如期望的正常用户访问量。在这个负载下，希望系统能够正常、稳定地运行。所以，在负载测试中，目的是确保系统在预期负载下工作正常。

压力测试目标是找出系统的瓶颈和上限。因此，我们会逐渐增加负载，超出正常的预期，直到系统出现问题或崩溃。在这个测试中，我们想知道系统能够承受多少负载，并且在达到极限时，系统的反应是怎样的。

所以，区分负载测试和压力测试主要是看测试目标和选择模拟的负载。如果已经知道系统预期要承受的负载，那么就进行负载测试。如果想要知道系统的极限和瓶颈在哪里，那就进行压力测试。

但在实际操作中，这两种测试可能会有所重叠。例如，可能首先进行负载测试，然后继续增加负载进行压力测试。因此，有时候确实需要根据测试的结果和系统的反应来进一步分析和定义测试的类别

3. 竞品分析

通过评估竞争对手或类似产品的性能，可以获得对行业标准或用户期望的见解。

详细介绍：

性能比较：可以使用工具或第三方服务测试和比较竞争对手的网站或应用的性能。这可以提供一个基准，告诉我们在哪里我们可能落后，或者哪里我们有优势。

用户期望：如果大多数竞品的加载时间都在2秒以下，而我们的产品需要5秒，那么用户可能会对我们的产品感到失望。

特性与性能的权衡：竞品分析也可以揭示特性与性能之间的权衡。例如，一个竞品可能加载得非常快，但它提供的功能比较少。

性能测试计划

给个例子：

用户管理系统测试计划

目标：

确保用户管理系统的所有功能都按照需求正常工作。
识别并修复所有关键和主要缺陷。
确保系统在预期的用户负载下稳定运行。

测试范围：

登录功能：用户登录、密码重置、记住密码、登出等。
用户管理：创建用户、删除用户、编辑用户、搜索用户、分配角色等。

测试策略：

单元测试：每个功能模块的单元测试。
集成测试：确保各个模块之间的交互没有问题。
系统测试：完整的系统功能测试。
性能测试：模拟多用户同时访问，检查系统的响应时间和稳定性。

测试环境：

测试服务器、数据库和相关配置。
测试数据准备。

进度和分工：

第一阶段：需求分析和测试用例设计

提交成果：需求分析报告、测试用例文档。

第二阶段：单元测试和集成测试

提交成果：单元测试脚本、集成测试脚本、测试日志、缺陷报告。

第三阶段：系统测试

提交成果：系统测试脚本、测试日志、缺陷报告、测试覆盖率报告。

第四阶段：性能测试

提交成果：性能测试脚本、性能测试报告、系统瓶颈分析报告。

第五阶段：回归测试

提交成果：回归测试脚本、测试日志、最终缺陷报告。

风险评估：

可能的技术挑战、人力或时间限制等。

资源：

需要的硬件、软件、人力资源列表。

总结与审计：

在测试结束后进行的回顾会议，总结本次测试的经验教训。

个人开发网站的指标要求

作者将来需要开发一个小的不能再小的网站。根据这个场景，下面是一些合理的性能期望：

吞吐量(QPS): 一个小型的网站，QPS可以是10-100之间。
并发量: 并发用户可能在10-100之间。
响应时间: 响应时间应该少于2秒。

如果网站QPS超过100，这是很好的，但也要确保服务器和数据库等可以处理这种负载。如果响应时间超过2秒，用户可能会觉得网站速度慢，应该考虑优化网站，比如通过减少图片大小、使用缓存等方法。如果QPS低于10，可能表示网站性能存在问题。如果并发量无法达到10或响应时间超过3秒，也表示网站可能需要优化和改进。