系统压力测试（一）

大家好，欢迎来到IT知识分享网。

《目录》

——–>认知，了解压测的一些参数，了解什么是正向的压测结果

——–>压测需求一般包含的东西与及步骤

——–>JMeter压测软件的介绍，压测计划中常用模块的用途

——–>了解怎么给出压测人员出一份压测指标，计算自己系统的合理吞吐量

——–>怎么看压测报告，一份报告都有哪些重点

一、认知

首先明确一点，压测的目的是为了观察当前系统的负载能!压测的结果一般情况可以通过吞吐量与并发数的比例来观察，吞吐量与并发数呈正相关关系，在一定并发数的情况下，吞吐量越高，说明系统性能越好!

开发的原因需要对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解：
1. 响应时间(RT)
　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
2. 吞吐量(Throughput)
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
3. 并发用户数
　　并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
4. QPS每秒查询率(Query Per Second)
　　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （类似于TPS，只是应用于特定场景的吞吐量）

二、如何做一个压测需求?

步骤1：压力测试分两种场景：

一种是单场景只压一个接口的；第二种是混合场景，多个有关联的接口。
压测时间，一般场景都运行10-15分钟。如果是疲劳测试，可以压一天或一周，根据实际情况来定。
步骤2：压测前要明确压测功能和压测指标，一般需要确定的几个问题：

固定接口参数进行压测还是进行接口参数随机化压测？
要求支持多少并发数？单接口多少，关联接口多少
TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？
被压的服务器名称或者被压的服务器IP，一般都是压测指定的服务器
步骤3：进行压测(详细见下面应用分析)

步骤4：压测分析与调整

有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；

Throughput吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数(线程数)，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；

压测结束，·登陆相应的web服务器查看CPU等性能指标，进行数据的分析;

最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。

最大的并发数：最大的并发数和最大的tps是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。
压测过程出现性能瓶颈，若压力机任务管理器查看到的cpu、网络和cpu都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题。
影响性能考虑点包括：数据库(重点)、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。
步骤5：出压测—>聚合报告

本次压测的要求指标，性能要求
本次压测的机器性能
本次压测的各项各项指标
本次压测的报告结果分析
压测报告建议
压测报告等级
三、介绍及入门

JMiter压测软件：一款通过不断提高对系统压力，用于测试系统性能，如负载，功能，性能，回归等；的有简洁明了的图形界面软件!

JMeter原理：向服务器提交请求并从服务器取回请求返回的结果

一般有如下一整个流程:

在JMeter中，一个完整的测试计划将包括一个或多个元素，如线程组，逻辑控制器，样品产生控制器，监听器，定时器，断言和配置元素。测试计划必须至少有一个线程组。一般分五个步骤:（1）添加线程组 （2）添加http请求 （3）在http请求中写入接入url、路径、请求方式和参数 （4）添加查看结果树 （5）调用接口、查看返回值。其作用和各自的功能如下：

1、 测试计划：测试的起点，其他配置原件的容器

2、线程组：代表一定数量的并发用户，它可以用来模拟并发用户发送请求

3、取样器Spamler：代表了各种各样的请求

4、监听器：负责收集测试结果，同时也被告知了结果显示的方式。功能是对取样器的请求结果显示、统计一些数据（吞吐量、KB/S……）等

5、断言：用于来判断请求响应的结果是否如用户所期望，是否正确。它可以用来隔离问题域，即在确保功能
正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。

6、定时器：负责定义请求（线程）之间的延迟间隔，模拟对服务器的连续请求。

7、逻辑控制器：允许自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。

8、配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。

9、前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。

三、应用与分析

1. 看性能分报告，一般一个JMeter有如下参数可以参考

2. 接口指标

5.聚合报告怎么看?

行业经验：对于游戏行业而言，对于性能的要求是非常高的，响应和延迟是其中最为重要的指标。其性能底线往往是要求90%用户的响应时间是在1秒内，对于2-3秒的用户响应只有一些非常小点击率的请求时才会适当允许! 对于一般的商业系统，性能不错的在1~2秒作用，3~5秒则稍微难以接受。这个性能指标是指90%的用户响应秒数。

TPS：吞吐量——默认情况下表示每秒完成的请求数（Request per Second)，当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数! tps越高说明服务器处理能力越好

Min：最小响应时间

Max：最大响应时间

90%Line ：90%请求的响应时间

Average ：每个请求的平均响应时间

Median ：中值，即50%请求的平均响应时间

Samples ：各个测试的样本总数 ，也即是说线程数*循环次数，

Error%：本次测试中出现错误的请求的数量/请求的总数

KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准

注意：如果初步设计压测的聚合报告，对很多参数不甚明了，那么可以重点关注TPS，MIN与MAX，Error%，以及90%Line这几个参数。它可以让你初步得到如下结论：

当并发在多少（线程数）的时候，每秒的TPS是多少，每秒的查询率QPS是多少QPS；当前系统90%Line用户的响应时间是多少，最长的响应时间是多少Max，最快的响应时间是多少MIN。压测中出现多少错误率Error，与目标允许的容错率xxxx 不符合/符合，请开发解决!
————————————————

原文链接：https://blog.csdn.net/qq_36505948/article/details/82425110