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

性能测试的基本⽅法与应⽤领域并发⽤户数、响应时间、系统吞吐量，这三个名词的含义可能就已经让你感觉云⾥雾⾥了，因此我会通过⼀个我们⽇常⽣活中的体检为例，再来解释⼀下它们到底是什么，以及它们之间的关系和约束。你先来想象这样⼀个场景：假设你找了⼀份新⼯作，⼊职前需要到体检中⼼完成⼊职体检。在体检中⼼做检查的过程，通常是先到前台登记个⼈信息并领取体检单，然后根据体检单的检查项⽬依次完成不同科室的检查。假设⼀共有5个科室，每个科室有3个候诊室，你发现体检中⼼有很多⼈都在做检查，那么你⼀般会选择先做排队⼈数较少的检查项⽬，直⾄完成5个科室的全部检查，最后离开体检中⼼。现在，我们做个类⽐：把整个体检中⼼想象成⼀个软件系统，从你进⼊体检中⼼到完成全部检查离开所花费的时间就是响应时间，⽽同时在体检中⼼参加体检的总⼈数就是并发⽤户数，那么系统吞吐量就可以想象成是单位时间内完成体检的⼈数，⽐如每⼩时100⼈。如果你到达体检中⼼的时间⽐较早，这时⼈还很少，5个科室都不⽤排队，那么你就能以最短的时间完成体检。也就是说，当系统的并发⽤户数⽐较少时，响应时间就⽐较短；但是由于整体的并发⽤户数少，所以系统的吞吐量也很低。从中，我们可以得出这样的结论：当系统并发⽤户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往把这个阶段称为 “空闲区间”。如果你到达体检中⼼时，这⾥的⼈已经⽐较多了，只有部分科室不需要排队，但好在每个科室都有3个候诊室同时进⾏检查，所以排队时间不会很长，你还是可以在较短的时间完成体检。也就是说，当系统的并发⽤户数⽐较多时，响应时间不会增加太多，因此系统的整体吞吐量也随着并发⽤户数的变⼤⽽变⼤的。从中，我们可以得出这样的结论：当系统整体负载并不是很⼤时，随着系统并发⽤户数的增长，系统的吞吐量也会随之呈线性增长，我们往往把这个阶段称为 “线性增长区间”。但是，当体检中⼼的⼈越来越多时，每个科室都需要排队，⽽且每个科室的队伍都很长，你每检查完⼀个项⽬都要花很长时间去排队进⾏下⼀个检查项⽬。这样⼀来，你完成体检的时间就会明显变长。也就是说，系统的并发⽤户数达到⼀定规模时，每个⽤户的响应时间都会明显变长，所以系统的整体吞吐量并不会继续随着并发⽤户数的增长⽽增长。从中，我们可以得出这样的结论：随着系统并发⽤户数的进⼀步增长，系统的处理能⼒逐渐趋于饱和，因此每个⽤户的响应时间会逐渐变长。相应地，系统的整体吞吐量并不会随着并发⽤户数的增长⽽继续呈线性增长。我们往往把这个阶段称为系统的“拐点”。最糟糕的情况来了，如果体检中⼼的⼈继续增加，你会发现连排队、站⼈的地⽅都没有了，所有⼈都被堵在了⼀起，候诊室中检查完的⼈出不来，排队的⼈⼜进不去。也就是说，系统的并发⽤户数已经突破极限，每个⽤户的响应时间变得⽆限长，因此系统的整体吞吐量变成了零。换⾔之，此时的系统已经被压垮了。从中，我们可以得出这样的结论：随着系统并发⽤户数的增长，系统处理能⼒达到过饱和状态。此时，如果继续增加并发⽤户数，最终所有⽤户的响应时间会变得⽆限长。相应地，系统的整体吞吐量会降为零，系统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。通过这个类⽐，相信你已经对并发⽤户数、响应时间和系统吞吐量理解得更透彻了，对于它们之间的关系和约束，也都了然于胸了。只有理解了这些主要性能指标之间的约束关系，我们才能在实际的性能测试实践中设计有的放⽮的性能测试场景。⽐如，后端性能测试的测试负载，我们⼀般只会把它设计在“线性增长区间”内；⽽压⼒测试的测试负载，我们则会将它设计在系统“拐点”上下，甚⾄是“过饱和区间”。那么，接下来让我们⼀起来看⼀下性能测试的⽅法都有哪些。常⽤的七种性能测试⽅法根据在实际项⽬中的实践经验，我把常⽤的性能测试⽅法分为七⼤类：后端性能测试（Back-end Performance Test）、前端性能测试（Front-end Performance Test）、代码级性能测试（Code-level Performance Test）、压⼒测试（Load/Stress Test）、配置测试（Configuration Test）、并发测试（Concurrence Test），以及可靠性测试（Reliability Test）。接下来，我将详细为你介绍每⼀种测试⽅法。第⼀，后端性能测试其实，你平时听到的性能测试，⼤多数情况下指的是后端性能测试，也就是服务器端性能测试。后端性能测试，是通过性能测试⼯具模拟⼤量的并发⽤户请求，然后获取系统性能的各项指标，并且验证各项指标是否符合预期的性能需求的测试⼿段。这⾥的性能指标，除了包括并发⽤户数、响应时间和系统吞吐量外，还应该包括各类资源的使⽤率，⽐如系统级别的CPU占⽤率、内存使⽤率、磁盘I/O和⽹络I/O等，再⽐如应⽤级别以及JVM级别的各类资源使⽤率指标等。由于需要模拟的并发⽤户数，通常在“⼏百”到“⼏百万”的数量级，所以你选择的性能测试⼯具，⼀定不是基于GUI的，⽽是要采⽤基于协议的模拟⽅式，也就是去模拟⽤户在GUI操作的过程中实际向后端服务发起的请求。只有这样才能模拟很⾼的并发⽤户数，尽可能地模拟出真实的使⽤场景，这也是现在所有后端性能测试⼯具所采⽤的⽅法。根据应⽤领域的不同，后端性能测试的场景设计主要包括以下两种⽅式：基于性能需求⽬标的测试验证；探索系统的容量，并验证系统容量的可扩展性第⼆，前端性能测试前端性能测试并没有⼀个严格的定义和标准。通常来讲，前端性能关注的是浏览器端的页⾯渲染时间、资源加载顺序、请求数量、前端缓存使⽤情况、资源压缩等内容，希望借此找到页⾯加载过程中⽐较耗时的操作和资源，然后进⾏有针对性的优化，最终达到优化终端⽤户在浏览器端使⽤体验的⽬的。⽬前，业界普遍采⽤的前端测试⽅法，是雅虎（Yahoo）前端团队总结的7⼤类35条前端优化规则，你可以通过查看这些规则，以及对各规则的详细解读。我在这⾥列出了其中⼏个最典型也是最重要的规则，来帮助你理解前端性能测试优化的关注范围。减少http请求次数：http请求数量越多，执⾏过程耗时就越长，所以可以采⽤合并多个图⽚到⼀个图⽚⽂件的⽅法来减少http请求次数，也可以采⽤将多个脚本⽂件合并成单⼀⽂件的⽅式减少http请求次数；减少DNS查询次数：DNS的作⽤是将URL转化为实际服务器主机IP地址，实现原理是分级查找，查找过程需要花费20~100ms的时间，所以⼀⽅⾯我们要加快单次查找的时间，另⼀⽅⾯也要减少⼀个页⾯中资源使⽤了多个不同域的情况；避免页⾯跳转：页⾯跳转相当于⼜打开⼀个新的页⾯，耗费的时间就会⽐较长，所以要尽量避免使⽤页⾯跳转；使⽤内容分发⽹络（CDN）：使⽤CDN相当于对静态内容做了缓存，并把缓存内容放在⽹络供应商（ISP）的机房，⽤户根据就近原则到ISP机房获取这些被缓存了的静态资源，因此可以⼤幅提⾼性能；Gzip压缩传输⽂件：压缩可以帮助减⼩传输⽂件的⼤⼩，进⽽可以从⽹络传输时间的层⾯来减少响应时间；第三，代码级性能测试代码级性能测试，是指在单元测试阶段就对代码的时间性能和空间性能进⾏必要的测试和评估，以防⽌底层代码的效率问题在项⽬后期才被发现的尴尬。如果你从事过性能测试相关的⼯作，⼀定遇到过这样的场景：系统级别的性能测试发现⼀个操作的响应时间很长，然后你要花费很多时间去逐级排查，最后却发现罪魁祸⾸是代码中某个实现低效的底层算法。这种⾃上⽽下的逐级排查定位的⽅法，效率通常都很低，代价也很⾼。所以，我们就需要在项⽬早期，对⼀些关键算法进⾏代码级别的性能测试，以防⽌此类在代码层⾯就可以被发现的性能问题，遗留到最后的系统性能测试阶段才被发现。但是，从实际执⾏的层⾯来讲，代码级性能测试并不存在严格意义上的测试⼯具，通常的做法是：改造现有的单元测试框架。最常使⽤的改造⽅法是：1. 将原本只会执⾏⼀次的单元测试⽤例连续执⾏n次，这个n的取值范围通常是2000~5000；2. 统计执⾏n次的平均时间。如果这个平均时间⽐较长（也就是单次函数调⽤时间⽐较长）的话，⽐如已经达到了秒级，那么通常情况下这个被测函数的实现逻辑⼀定需要优化。这⾥之所以采⽤执⾏n次的⽅式，是因为函数执⾏时间往往是毫秒级的，单次执⾏的误差会⽐较⼤，所以采⽤多次执⾏取平均值的做法。第四，压⼒测试压⼒测试，通常指的是后端压⼒测试，⼀般采⽤后端性能测试的⽅法，不断对系统施加压⼒，并验证系统化处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态时的主要瓶颈点。所以，压⼒测试往往被⽤于系统容量规划的测试。还有些情况，在执⾏压⼒测试时，我们还会故意在临界饱和状态的基础上继续施加压⼒，直⾄系统完全瘫痪，观察这个期间系统的⾏为；然后，逐渐减⼩压⼒，观察瘫痪的系统是否可以⾃愈。第五，配置测试配置测试，主要⽤于观察系统在不同配置下的性能表现，通常使⽤后端性能测试的⽅法：1. 通过性能基准测试（Performance Benchmark）建⽴性能基线（Performance Baseline）；2. 在此基础上，调整配置；3. 基于同样的性能基准测试，观察不同配置条件下系统性能的差异，根本⽬的是要找到特定压⼒模式下的最佳配置。这⾥需要注意的是，“配置”是⼀个⼴义配置的概念，包含了以下多个层⾯的配置：宿主操作系统的配置；应⽤服务器的配置；数据库的配置；JVM的配置；⽹络环境的配置；…第六，并发测试并发测试，指的是在同⼀时间，同时调⽤后端服务，期间观察被调⽤服务在并发情况下的⾏为表现，旨在发现诸如资源竞争、资源死锁之类的问题。谈到并发测试，我就不得不和你说说“集合点并发”的概念了，它源于HP的LoadRunner，⽬前已经被⼴泛使⽤了。那，到底什么是“集合点并发”呢？假设我们希望后端调⽤的并发数是100，如果直接设定100个并发⽤户是⽆法达到这个⽬标的，因为这100个并发⽤户会各⾃执⾏各⾃的操作，你⽆法控制某⼀个确定的时间点上后端服务的并发数量。为了达到准确控制后端服务并发数的⽬的，我们需要让某些并发⽤户到达该集合点时，先处于等待状态，直到参与该集合的全部并发⽤户都到达时，再⼀起向后端服务发起请求。简单地说，就是先到的并发⽤户要等着，等所有并发⽤户都到了以后，再集中向后端服务发起请求。⽐如，当要求的集合点并发数是100时，那么前99个到达的⽤户都会等在那⾥，直到第100个⽤户到了，才集中向后端服务发起请求。当然，实际达到服务器的并发请求数，还会因为⽹络延迟等原因⼩于100。所以，在实际项⽬中，我建议在要求的并发数上进⾏适当放⼤，⽐如要求的并发数是100，那我们集合点并发数可以设置为120。第七，可靠性测试可靠性测试，是验证系统在常规负载模式下长期运⾏的稳定性。虽然可靠性测试在不同公司的叫法不同，但其本质就是通过长时间模拟真实的系统负载来发现系统潜在的内存泄漏、链接池回收等问题。由于真实环境下的实际负载，会有⾼峰和低⾕的交替变化（⽐如，对于企业级应⽤，⽩天通常是⾼峰时段，⽽晚上则是低峰时段），所以为了尽可能地模拟出真实的负载情况，我们会每12⼩时模拟⼀个⾼峰负载，两个⾼峰负载中间会模拟⼀个低峰负载，依次循环3-7天，形成⼀个类似于“波浪形”的系统测试负载曲线。然后，⽤这个“波浪形”的测试负载模拟真实的系统负载，完成可靠性测试。同样地，可靠性测试也会持续3-7天。聊完了常⽤性能测试⽅法的种类后，我们再来简单看⼀下性能测试的四⼤应⽤领域，以及每个应⽤领域都会使⽤哪些性能测试⽅法。性能测试的四⼤应⽤领域不同的性能测试⽅法适⽤于不同的应⽤领域去解决不同的问题，这⾥“不同的应⽤领域”主要包括能⼒验证、能⼒规划、性能调优、缺陷发现这四⼤⽅⾯。每个应⽤领域可以根据⾃⾝特点，选择合适的测试⽅法。第⼀，能⼒验证能⼒验证是最常⽤，也是最容易理解的性能测试的应⽤领域，主要是验证“某系统能否在A条件下具有B能⼒”，通常要求在明确的软硬件环境下，根据明确的系统性能需求设计测试⽅案和⽤例。能⼒验证这个领域最常使⽤的测试⽅法，包括后端性能测试、压⼒测试和可靠性测试。第⼆，能⼒规划能⼒规划关注的是，如何才能使系统达到要求的性能和容量。通常情况下，我们会采⽤探索性测试的⽅式来了解系统的能⼒。能⼒规划解决的问题，主要包括以下⼏个⽅⾯：能否⽀持未来⼀段时间内的⽤户增长；应该如何调整系统配置，使系统能够满⾜不断增长的⽤户数需求；应⽤集群的可扩展性验证，以及寻找集群扩展的瓶颈点；数据库集群的可扩展性验证；缓存集群的可扩展性验证；…能⼒规划最常使⽤的测试⽅法，主要有后端性能测试、压⼒测试、配置测试和可靠性测试。第三，性能调优性能调优，其实是性能测试的延伸。在⼀些⼤型软件公司，会有专门的性能⼯程（Performance Engineering）团队，除了负责性能测试的⼯作外，还会负责性能调优。性能调优主要解决性能测试过程中发现的性能瓶颈的问题，通常会涉及多个层⾯的调整，包括硬件设备选型、操作系统配置、应⽤系统配置、数据库配置和应⽤代码实现的优化等等。这个领域最常⽤的测试⽅法，涵盖了我在上⾯分享的七⼤类测试⽅法，即后端性能测试、前端性能测试、代码级性能测试、压⼒测试、配置测试、并发测试和可靠性测试。第四，缺陷发现缺陷发现，是⼀个⽐较直接的应⽤领域，通过性能测试的各种⽅法来发现诸如内存泄露、资源竞争、不合理的线程锁和死锁等问题。缺陷发现，最常⽤的测试⽅法主要有并发测试、压⼒测试、后端性能测试和代码级性能测试。上⾯这些内容就是性能测试的常⽤⽅法和应⽤领域了，我⽤⼀张表汇总了各个应⽤领域需要⽤到的测试⽅法，希望可以帮助你记忆、理解。 后端性能测试前端性能测试代码级性能测试压⼒测试配置测试并发测试可靠性测试能⼒验证√

√

√能⼒规划√

√√

√性能调优√√√√√√√缺陷发现√

√√

√

总结今天我通过⼀个⽣活中“体检”的实例，和你分享了并发⽤户数、响应时间和系统吞吐量三者之间的关系：当系统整体负载并不是很⼤时，随着并发⽤户数的增长，系统的吞吐量也会随之线性增长；随着并发⽤户数的进⼀步增长，系统处理能⼒逐渐趋于饱和，因此每个⽤户的响应时间会逐渐变长，相应地，系统的整体吞吐量并不会随着并发⽤户数的增长⽽继续线性增长。如果并发⽤户数再继续增长，系统处理能⼒达到过饱和状态，此时所有⽤户的响应时间会变得⽆限长，相应地，系统的整体吞吐量会降为零，系统处于被压垮的状态。