2023年7月11日发(作者：)

性能压测总结（上）-测试策略和分析前⾔本⽂的重⼼放在了前期的分析和策略准备上，也是希望⼤家先思考后⾏动，毕竟压测本⾝也算是个复杂的⼯程。压测后的问题分析和调优，后续再找机会梳理下。需求分析确认性能测试的需求来源，⼀般有这⼏种： ⽇常迭代，性能基线摸底 统⼀指标，固定环境，主要关注关键指标的变化 重⼤活动，业务事件前的摸底测试 着重考察⾼压⼒情况下的服务表现 摸⾼测试，找到性能瓶颈点 为⽔平扩容提供数据依据（即在当前性能表现下，为了要满⾜**业务需求，我们还需要**机器） 功能⾸次上线，对系统的⾸次评估 ⼀般会涉及到⼀次摸底测试，找到系统极限 同时记录性能基线，为后续巡检提供数据对⽐ 另外针对项⽬类型，⼜区分公有云/私有化部署，需要确认部署环境。 常见的⼏种性能测试类型：常见的⼏种性能测试类型：基准测试基准测试是指模拟单个⽤户执⾏业务场景，监控系统的性能指标与服务器资源。严格来说，基准测试不属于性能测试的范畴，它与功能测试其实没有太⼤的区别。基准测试的⽬的更多的是关注业务功能及验证脚本的⼀个准确性，然后，将基准测试时采集到的结果（各项性能指标及服务器硬件资源）作为后续并发测试性能分析的⼀个参考依据。负载测试负载测试是模拟系统在正常负载压⼒场景下，考察系统的各项性能指标。这⾥说的正常负载，主要是指⽤户对系统能承受的最⼤负载量的期望值。即预计系统最⼤可⽤⽀持的业务并发⽤户数。通过负载测试，可以验证系统是否能满⾜我们预期的⼀个业务压⼒场景。通过负载测试，得到系统的性能拐点（最佳性能点），当达到这个点时，系统的极限与表现能⼒⼜是多少。负载测试也经常⽤于线上流量评估。压⼒测试压⼒测试是测试系统在多⼤并发压⼒下系统的性能会变得不可接受，或者出现性能拐点（崩溃）。在加压策略上，压⼒测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的⾛势情况，最终找出系统在出现性能拐点时的并发⽤户数，也就是系统⽀持的最⼤并发⽤户数。压⼒测试主要⽤于测试系统或系统某些部分的极限能⼒。通过⼀直增加负载，直到应⽤的部分功能不能正常⼯作，压⼒测试的⽬的是找到被测系统的容量天花板。负载测试和压⼒测试区别负载测试是验证系统是否满⾜预期的业务压⼒场景；⽽压⼒测试是找到测试系统的容量天花板。负载测试是模拟多个⽤户不同时间段内持续向系统发送请求的，⽽压⼒测试是模拟同⼀时间段内持续不断的向系统发送请求的。疲劳强度测试疲劳强度测试与负载测试testing觉得挺接近的，都是对系统模拟出系统能承受的最⼤业务负载量。差异在于，疲劳强度测试的侧重点是系统在长时间运⾏情况下系统各项性能指标的变化情况。例如：系统在运⾏24 * 3后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等性能问题。稳定性测试稳定性测试是指被测系统被⽤户正常的使⽤，能持续多长时间运⾏⽽不出现错误。疲劳强度测试是指被测系统可以⽀持的最⼤并发数长时间模拟运⾏业务，通过资源和性能指标侧⾯分析系统的稳定性。容量测试当系统业务越来越复杂的时候，⽐如双⼗⼀、春节等⼤促。我们应该怎么评估线上的性能？如何去做合理的扩容？这个时候就需要开展相应的容量测试了。测试策略明确测试接⼝和链路从产品需求中明确需求，熟悉待测试接⼝。⼀般区分读接⼝和写接⼝，例如媒资上传链路中，涉及到媒资增加和媒资上传完成后的状态查询接⼝。读接⼝ 注意是否会触发缓存机制，导致压⼒到不了数据库 注意本⾝数据库数据量问题，确认真实业务中库表中数据量级 分库分表场景下注意是否需要考虑热点库表情况写接⼝ 注意接⼝是同步返回还是异步返回 注意是否需要构造参数化数据，相同数据写⼊是否有缓存逻辑，幂等逻辑 注意是否需要有前提数据准备还有其他⽐较特殊的 主要体现在业务上为异步处理，不纠结接⼝响应，重点考核⼀段时间内的处理能⼒。典型：视频转码能⼒（考核倍速指标、**分钟内处理完成**分钟原始视频），视频合成能⼒（类似转码） 注意考察单节点/集群处理能⼒的区别 注意是否有调度节点，调度节点是否可能成为瓶颈 注意尝试长时间测试观察稳定性 注意输⼊数据是否有各种格式区别，可能会影响最终结果明确测试环境 选择被测试应⽤是在哪个环境？ case：⽣产环境 测试导致的业务服务器压⼒⼤，是否会对线上⽤户使⽤造成影响 测试导致的中间件压⼒⼤，是否会对同时使⽤该中间件的其他业务系统造成影响 测试产⽣的⼤量数据，是否可以清理，是否会对下游应⽤的数据有污染 ⽐如，产⽣⼤量的媒资数据，对于数据统计，BI报表，计费流量是否有影响？ case：测试环境 环境是否可以保证稳定可⽤，测试期间降低部署频率 环境资源配置是否需要提前调整，和线上保持⼀致or等⽐例调整 测试链路上的各应⽤代码版本尽可能保持⼀致 case：单独的性能环境 部署的应⽤链路是否完整 测试链路上的各应⽤代码版本是否是待测试版本 施压机器在什么环境？ 访问被测试应⽤需要是公⽹访问还是内部访问 施压机器是否会有瓶颈明确性能指标 重点要关注哪些指标，这些指标的预期值为多少 可以由产品确定 也可以参考之前的性能基线1、响应时间响应时间指的是“系统响应时间”，定义为应⽤系统从发出请求开始到客户端接收到响应所消耗的时间。把它作为⽤户视⾓的软件性能的主要体现。它包括⽹络上的传输时间，web服务器上处理时间，APP服务器上处理时间，DB服务器上处理时间，但不包括浏览器上的内容显⽰时间，即“呈现时间”，这是因为呈现时间在很⼤程度上取决于客户端的表现。2、最⼤并发⽤户数有两种理解⽅式，⼀种是从业务的⾓度来模拟真实的⽤户访问，体现的是业务并发⽤户数，指在同⼀时间段内访问系统的⽤户数量。另⼀种是从服务器端承受的压⼒来考虑，这⾥的“并发⽤户数”指的是同时向服务器端发出请求的客户数，该概念⼀般结合并发测试（Concurrency Testing）使⽤，体现的是服务端承受的最⼤并发访问数。3、吞吐量吞吐量是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能⼒。⼀般来说，吞吐量⽤请求数/秒或是页⾯数/秒来衡量，从业务的⾓度，吞吐量也可以⽤访问⼈数/天或是处理的业务数/⼩时等单位来衡量。当然，从⽹络的⾓度来说，也可以⽤字节数/天来考察⽹络流量。对于交互式应⽤来说，吞吐量指标反映的是服务器承受的压⼒。4、性能计数器性能计数器（Counter）是描述服务器或操作系统性能的⼀些数据指标。例如，对Windows 系统来说，使⽤内存数（Memory In Usage），进程时间（Total Process Time）等都是常见的计数器。5、思考时间思考时间（Think Time），也被称为“休眠时间”，从业务的⾓度来说，这个时间指的是⽤户在进⾏操作时，每个请求之间的间隔时间。从⾃动化测试实现的⾓度来说，要真实地模拟⽤户操作，就必须在测试脚本中让各个操作之间等待⼀段时间，体现在脚本中，具体⽽⾔，就是在操作之间放置⼀个Think 的函数，使得脚本在执⾏两个操作之间等待⼀段时间。6、TPSTPS:Transaction per second，每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能⼒的重要指标。7、HPS点击率：HPS，每秒钟⽤户向WEB服务器提交的HTTP请求数。这个指标是WEB应⽤特有的⼀个指标，WEB应⽤是”请求—响应”模式，⽤户发出⼀次申请，服务器就要处理⼀次，所以点击是WEB应⽤能够处理的交易的最⼩单位。8、资源利⽤率资源利⽤率就是指资源的使⽤情况，如CPU使⽤率、内存使⽤率、⽹络宽带的使⽤情况、磁盘I/O的输⼊输出量等系统硬件⽅⾯的监控指标。⼀个完整的系统是由软件和硬件组成，缺了任何⼀⽅都不可能成为⼀个正常运作的系统，所以资源利⽤率也是测试⼈员的⼀个监控点，并在当前软件的发展趋势下，硬件资源的成本也不可⼩视。明确压测时间 ⼀般根据业务情况选择 要考虑执⾏时对现有⽤户的影响，线上⽤户/测试环境中其他在测试的同学 要考虑同时间段有没有其他任务在执⾏，⽐如半夜的数据库备份，定时的统计任务等测试准备测试⼯具选择 ⾃研性能压测平台 ⾃⼰写脚本测试数据准备 请求数据准备 依赖数据准备，例如：账号，数据库中的基础数据（⼜叫垫底数据）测试环境的准备 确认环境可⽤稳定 确认环境中代码是待测试版本策略评审 评审⼀定要做评审⼀定要做 关键责任⼈：业务⽅、产品经理、被测试应⽤开发、相关应⽤开发（由被测试应⽤开发确认通知范围）执⾏期间 注意观察被压测应⽤ 观察并记录性能指标 出现异常时，及时记录⽇志 or requestId，不然可能被淹没或者覆盖 出现堵塞或者异常，及时解决 每⼀轮测试结束后，按计划调整测试参数 *注意观察施压机器，别因为施压机器的资源瓶颈，导致性能指标下降 服务器监控 服务器监控 跳板到对应服务机器，linux top命令 Grafana平台 特殊的是，部分场景，涉及到数据库中捞取⼀些业务数据⽤来计算结果测试结论确定 基于上述的不同的测试⽬的，得出测试结论对于⼀个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发⽤户数”和“最⼤并发⽤户数”都是客观存在。以“最佳并发⽤户数”为例，假如⼀个系统的最佳并发⽤户数是50，那么⼀旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期⼤于这个数，必然会导致⽤户的满意度降低并最终达到⼀种⽆法忍受的地步。所以我们应该 保证最佳并发⽤户数要⼤于系统的平均负载。要补充的⼀点是，当我们需要对⼀个系统长时间施加压⼒——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使⽤的并发⽤户数应该等于或⼩于“最佳并发⽤户数”——⼤家也可以结合上⾯的讨论想想这是为什么 ^_^⽽对于最⼤并发⽤户数的识别，需要考虑和鉴别⼀下以下两种情况：1. 当系统的负载达到最⼤并发⽤户数后，响应时间超过了⽤户可以忍受的最⼤限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该⼩于5秒。这⾥容易疏忽的⼀点是，不要把顾客因为⽆法忍受⽽离开时店内的顾客数量作为理发店的“最⼤并发⽤户数”，因为这位顾客是在3⼩时前到达的，也就是说3⼩时前理发店内的顾客数量才是我们要找的“最⼤并发⽤户数”。⽽且，这位顾客的离开只是⼀个开始，可能有会更多的顾客随后也因为⽆法忍受超长的等待时间⽽离开；2. 在响应时间还没有到达⽤户可忍受的最⼤限度前，有可能已经出现了⽤户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有⼀位顾客打道回府，改天再来。对于⼀个系统来说，我们应该 确保系统的最⼤并发⽤户数要⼤于系统需要承受的峰值负载。后续推进 主要是在排查和分析性能瓶颈产⽣原因。