一、性能测试概念与入门

问题：

                什么是并发、什么是并行？

回答：

                并发：同一时间点，发起请求，这个请求可以相同，也可以不同。性能测试中，宏观的并发，可以是不同的请求，微观并发，是相同的请求。如：该系统有80人，向服务器发起请求持续1分钟，一共发送8000次。8000次/60s = 134次/s。就是每秒并发数。（这里的8000次一定是处理完了，收到了处理响应。因为http协议是一个同步协议，即发出去的请求一定要收到响应才会发起下一次请求。服务器的处理能力越强，每秒请求次数就会大于134次。）

        并行：同时做多件事情

2.1.2 基准测试：

当项目还没做过性能测试时，所有的性能指标数据都没有。就把第一次正式执行性能测试得到的性能指标数据，作为一个基准。

基准就是一个参考点【基准线】，如果有新硬件/代码架构调整/服务器升级等操作，可以先做基准测试，等升级完后再做一遍测试跟基准测试数据对比，确认本次升级对性能的影响。

比如：

JDK ：1.8 版本，得到指标： RT TPS 错误率等一组数据可以做为基准数据；

升级jdk22版本，再次压同样的脚本，依然得到一组指标数据，跟上次对比；如果数据下降了不升级jdk；数据上升了升级jdk

2.1.3 负载测试：

逐步增加并发用户数，向服务器发起请求，观察各种性能指标数据，通过这些指标数据的分析、判断出服务器最大可接受的并发用户数，或最大并发用户数。

如果去执行负载测试-Jmeter的阶梯压测的模型去实施后面讲工具的时候会讲到。

指标： TPS 响应时间错误率等，觉得有异常到系统的极限了或者系统崩溃了，这个时候的用户数就是系统的最大并发数。

问题：

        最大并发用户数与最大可接受的并发用户数的区别

最大并发用户数：

        当服务器出现持续的请求报错，资源利用率过高的时候，这个时候的并发用户数

最大可接受的并发用户数：

        满足可接受标准的时候的并发用户数，我们做性能测试时，使用的并发用户数。

可接受的标准(业内标准)：http协议的平均响应时间(单接口)小于1.5s；错误率要小于0.1%；服务器的资源利用率小于80。(可根据项目要求灵活调整)

接口性能响应时间，是不包括前端渲染时间

基本上性能测试都是先用负载测试找到系统能承受的最大并发用户数，然后 再用这个用户数做性能测试。

2.1.4 性能测试：

通过负载测试找到最大可接受的并发用户数持续请求一段时间，获得性能指标数据，然后通过这些指标数据，判断是否存在性能问题；如果有性能问题，进行性能分析、调优，再测试验证。

执行时间：几分钟 -几十分钟左右【5分钟】

2.1.5 压力测试：

通过施加超出正常操作范围的并发用户请求，找到系统的性能瓶颈和极限，观察系统在高负载条件下的响应和验证恢复能力。

问题：

        使用一定量的并发 用户数来请求：用户数具体为多少呢？时间一般压多久？

用户数:

        超过最大可接受的用户数，逐步增加，直到系统无法正常响应或者崩溃(通过负载测试系

统承受最大并发100，+10...)

时间长：

        逐步增加，时间不会很长，几分钟几十分钟..

        这个一定是先做过负载测试得到了系统承受最大并发用户数。

关注：

        压力停掉之后系统的自我恢复能力，资源释放掉内存释放等。

使用场景：

        有些项目应对高并发高流量需要做压力测试，电商社交媒体等应对突发流量的场景双十一等；

2.1.6 稳定性测试(可靠性测试)：

验证长期运行的稳定性和可靠性，确保系统在正常负载下长期运行时没有性能下降、内存泄漏或者其他问题。观察系统在长时间运行后的资源使用情况，发现长期运行中可能出现的性能问题和资源耗尽问题。

问题：

        长时间运行的时间具体多久？用户数一般多少？

运行时间：

        模拟真实环境下长期使用，运行时间从几小时-几天- 几周不等；具体时间看项目和测试场景而定；

用户数：

        基于负载测试得到的最大能承受的并发用户数而定。

低并发做稳定性：

        20% 最大能承受的并发用户数：如果发现了问题更好定位

高并发做稳定性:

        80% 最大能承受的并发用户数。

使用场景：

        需要长期稳定运行的项目，比如银行证券交易对于故障容忍度很低，需要做稳定性测试

2.1.7 拓展 - 并发用户数&账号

并发用户：模拟的人

账号：系统中的唯一标识用户的信息

两者并没有强关联关系，如一个人可以用多个账号，或者一个账号被多个人使用。所以并发用户数是指人数，不是账号数。

问题：

        是否可以用一个账号测试呢？还是说要准备一批账号？

答：

        如果被测系统，一个账户可以反复登录并且登录之后身份信息不变如token，可以只使用一个账号；

        如果每次登录身份信息会失效则需要准备一批账号。一般情况下，建议做性能测试，使用多个账号，且账号数要远远大于并发用户数。

3、总结性概念

此处引用楼高老师的《性能30讲》，因为传统的概念理解成本较高，概念之间的界限非常模糊。有幸读过楼高老师的专栏，认为相比较传统概念，以下总结性的概念易理解，对企业和工作人员来说更容易做好性能测试。

3.1性能测试需要有指标

有人说，我们在做项目的时候，就没有指标，老板只说一句，系统压死为止。听起来很儿戏，但这样的场景不在少数。在我看来，把系统压死也算是一种指标。至于你用什么手段把系统“压死”，那就是实现的问题了。你可以采用很多种手段，告诉老板，这系统还没压就死了！这也是你的贡献。

而对“有指标”这个定义来说，理论上合理的，并且应该有的指标是：时间指标、容量指标和资源利用率指标。关于这些指标的概念，会在后续篇幅中详细说明

3.2 性能测试需要有模型

模型是什么？它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。

这种做法需要的数据通常都是从生产环境中的数据中统计来的，很多在线上不敢直接压测的企业都是这样做的。

而随着互联网中零售业、云基础架构的全面发展，有些企业直接在线上导流来做性能测试，这种思路上的转变来源于架构的发展及行业的真实需要。但这并不能说明性能测试不需要模型了，因为这个模型已经从生产流量中导过来了。这一点，还是需要你认清的。

但是对于其他的一些行业，比如银行这类金融机构，线上一个交易都不能错。像上面这样做的难度就太大了。所以这些行业中，仍然需要在测试环境中用业务模型来模拟出生产的流量。

性能测试也要选择适合自己系统业务逻辑的方式，用最低的成本、最快的时间来做事情。

3.3 性能测试要有方案

方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了，这些内容具体的信息还需要精准。

你可能会说，怎么没有测试计划？我的建议是，用项目管理工具单独画测试计划，比如用 Project 或 OmniPlan 之类的工具。这是因为在方案中，写测试计划，基本上只能写一个里程碑，再细化一点，就是在里面再加几个大阶段的条目。但是用项目管理工具做计划就不同了，它不仅可以细分条目，还能跟踪各个工作的动态进度，可以设置前后依赖关系，填入资源和成本以便计算项目偏差。

3.4 性能测试中要有监控

这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力。关于这一点，将在后续的篇幅中详细说明

3.5 性能测试要有预定的条件

这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说，在场景执行之前，这些条件应该是确定的。

有人说，我们压力中也会动态扩展。没问题，但是动态扩展的条件或者判断条件，也是有确定的策略的，比如说，我们判断 CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时，就做动态扩展。这些也是预定的条件。

3.6 性能测试中要有场景

可以说，“性能场景”这个词在性能测试中占据着举足轻重的地位，只是我们很多人都不理解“场景”应该如何定义。场景来源于英文的 scenario，对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

3.7 性能测试中要有分类

3.7.1、基准性能场景：

这里要做的是单交易的容量，为混合容量做准备（不要跟我说上几个线程跑三五遍脚本叫基准测试，在我看来，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类）。

3.7.2、容量性能场景：

这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个，在概念部分就不细展开了，我会在后面的文章中详细说明。

3.7.3、稳定性性能场景：

稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。

3.7.4、异常性能场景：

要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。这个异常的定义是很宽泛的，在后边的篇幅中，我们再细说。

很多性能测试工程师，都把场景叫成了测试用例。如果只是叫法不同，我觉得倒是可以接受，关键是内容也出现了很大的偏差，这个偏差就是，把用例限定在了描述测试脚本和测试数据上，并没有描述需要实时的判断和动态的分析。这就严重影响了下一个概念：性能结果。

3.8 性能测试中要有分析调优

从性能市场的整体状态来看，在性能测试工程师中，可以做瓶颈判断、性能分析、优化的人并不多，所以很多其他职位上的人对性能测试的定位也就是性能验证，并不包括调优的部分。于是有很多性能项目都定义在一两周之内。这类项目基本上也就是个性能验证，并不能称之为完整的性能项目。而加入了调优部分之后，性能项目就会变得复杂。对于大部分团队来说，分析瓶颈都可能需要很长时间，这里会涉及到相关性分析、趋势分析、证据链查找等等手段。所以，就要不要进行调优，我做了如下划分。

对性能项目分类

1. 新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。

2. 旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。

3. 新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好。

对性能团队的职责定位分类。

1. 性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。

2. 性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。

3. 性能测试 + 分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。

2.8 性能测试肯定要有结果报告

有了前面监控的定义，有了场景执行的过程，产生的数据就要整理到结果报告中了。这个文档工作也是很重要的，是体现性能团队是否专业的一个重要方面。测试报告是需要汇报或者归档的。

我们要知道，大部分老板或者上司关心的是测试的结果，而不是用了多少人，花了多少时间这些没有意义的数字。我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图。

通过图示最后总结一下性能测试的概念：

问题：被测项目性能越好，jmeter产生的并发用户数越少吗?

答: 项目性能越好，说明服务的处理能力就越强，jmeter发到服务器的请求，就能越快被处理。比如：http同步协议，当前一次的请求服务处理完成后响应给jmeter，jmeter响应后就会马上发起下一个请求....则很短时间内就会完成很多次请求，那么并发用户数就会更少。

3.9 拓展

注：来看一些关系图，出自高楼老师的《性能30讲》

在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。

1. 三条曲线：吞吐量的曲线（紫色）、利用率（绿色）、响应时间曲线（深蓝色）。

2. 三个区域：轻负载区（Light Load）、重负载区（Heavy Load）、塌陷区（Buckle Zone）。

3. 两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）。

4. 三个状态描述：资源饱和（Resource Saturated）、吞吐下降（Throughput Falling）、用户受影响（End Users Effected）。

做为一个示意图，它真的非常经典，的确描述出了一个基本的状态。但是，示意图也只能用来做示意图，在具体的项目中，我们仍然要有自己明确的判断。

我们要知道，这个图中有一些地方可能与实际存在误差。

首先，很多时候，重负载区的资源饱和，和 TPS 达到最大值之间都不是在同样的并发用户数之下的。比如说，当 CPU 资源使用率达到 100% 之后，随着压力的增加，队列慢慢变长，响应时间增加，但是由于用户数增加的幅度大于响应时间增加的幅度之前，TPS 仍然会增加，也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。

大部分情况下，响应时间的曲线都不会像图中画得这样陡峭，并且也不一定是在塌陷区突然上升，更可能的是在重负载区突然上升。

另外，吞吐量曲线不一定会出现下降的情况，在有些控制较好的系统中会维持水平。曾经在一个项目中，因为 TPS 维持水平，并且用户数和响应时间一直都在增加，由于响应时间太快，一直没有超时。我跟我团队那个做压力的兄弟争论了三个小时，我告诉他接着压下去已经没有意义，就是在等超时而已。他倔强地说，由于没有报错，时间还在可控范围，所以要一直加下去。关于这一点争论，我在后续的文章中可能还会提及。

最优并发数这个点，通常只是一种感觉，并没有绝对的数据用来证明。在生产运维的过程中，其实我们大部分人都会更为谨慎，不会定这个点为最优并发，而是更靠前一些。

最大并发数这个点，就完全没有道理了，性能都已经衰减了，最大并发数肯定是在更前的位置呀。这里就涉及到了一个误区，压力工具中的最大用户数或线程数和 TPS 之间的关系。在具体的项目实施中，有经验的性能测试人员，都会更关心服务端能处理的请求数即 TPS，而不是压力工具中的线程数。

这张图没有考虑到锁或线程等配置不合理的场景，而这类场景又比较常见。也就是我们说的，TPS 上不去，资源用不上。所以这个图默认了一个前提，只要线程能用得上，资源就会蹭蹭往上涨。

我们简化出另一个图形，以说明更直接一点的关系。如下所示：

上图中蓝线表示 TPS，黄色表示响应时间。

在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）。

最后，响应时间过长，达到了超时的程度。

下面我将用场景的定义来替换这些混乱的概念

为什么要如此划分？因为在具体场景的操作层面，只有场景中的配置才是具体可操作的。而通常大家认为的性能测试、负载测试、压力测试在操作的层面，只有压力工具中线程数的区别，其他的都在资源分析的层面，而分析在很多人的眼中，都不算测试。

拿配置测试和递增测试举例吧。

在性能中，我们有非常多的配置，像 JVM 参数、OS 参数、DB 参数、网络参数、容器参数等等。如果我们把测试这些配置参数，称为“配置测试”，我觉得未免过于狭隘了。因为对于配置参数来说，这只是做一个简单的变更，而性能场景其实没有任何变化呀。配置更改前后，会用同样的性能场景来判断效果，最多再增加一些前端的压力，实际的场景并没有任何变化，所以，我觉得它不配做为一个单独的分类。

再比如递增测试，在性能中，基准性能场景也好，容量性能场景也好，哪个是不需要递增的呢？我知道现在市场上经常有测试工程师，直接就上了几百几千线程做压力（请你不要告诉我这是个正常的场景，鉴于我的精神有限，承受不了这样的压力）。除了秒杀场景，同时上所有线程的场景，我还没有见到过。在一般的性能场景中，递增都是必不可少的过程。同时，递增的过程，也要是连续的，而不是 100 线程、200 线程、300 线程这样断开执行场景，这样是不合理的。关于这一点，我们将在很多地方着重强调。所以我觉得递增也不配做一个单独的分类。

http协议传输数据的时候，规定报文中必须包含“发起发ip:端口 + 请求数据 + 目的地ip:端口”

发起方端口：每个请求，就要一个端口。但是机器的端口是有限的，目前理论最大值是64位65535个端口。如果端口不够用，请求就会失败。

解决端口不够用报错方案：

1、将长链接变为短连接，释放端口速度快

长连接：数据传输完一段时间之后才会断开连接

短连接：数据传输完之后就断开连接

2、加发请求机器(分布式)

容量测试：就是服务器的数据库的数据量级在不同的情况下的性能测试。(表的数据量级：十万、百万、千万)测试环境尽量与生产数据量保持一致