一次性能测试的过程

一、 性能测试目的     性能也是一个产品质量模型中的类型，当测试一个产品系统时，我们也会关注产品的性能，比如前端页面的渲染时间或者接口访问的响应时间，或者更深层次的性能测试，比如大量访问时服务的响应时间、成功率等。     对于一个系统要不要做深层次的性能测试，是要对系统进行评估的，是不是有必要做，毕竟做性能测试的成本不低。一般而言我们会针对有一定用户量的系统或者某个时间段突然激增用户访问的系统才评估做性能测试。     我这次面对的系统是高端地产相关的智慧通行系统（多微服务+gateway+Redis+MySQL+阿里云K8S+第三方系统），使用的用户主要是员工或者住户。按照目前的用户量，我们是可以不做性能测试的，但是为了评估下系统的承载量，我们还是做了个简单的压测方案，我们的性能测试主要目的是：     a). 评估这个系统在大量访问情况下的响应时间和成功率；     b). 系统或者服务能承受的访问量和QPS; 二、 性能测试场景分析      既然决定要做性能测试了，那在做性能测试之前我们得明确几点：     1. 测试指标——这次性能测试是要检验哪些，关注哪些指标数据。     对于这个系统我们目的很明确就是在当前使用的软硬件资源下，系统能否处理用户的的并发访问：能快速正常的响应用户的请求。那我们关注的指标就是响应时间、成功率，及预估系统能承载的QPS，还有在最大请求量范围内资源的利用率，比如内存、CPU之类的。     2. 测试场景——从测试目的配合业务，设计这次性能测试的场景，涉及哪些接口，这些接口怎么配合测。     比如在这个智慧通行系统里，用户最频繁使用的是通行码（A服务），上班高峰期用户量最多，那这个场景我们就可以作为性能测试的场景，我们理出这个场景下涉及到的接口；但从接近真实性来看性能测试时又不能只考虑这一个场景，因为系统还有其他功能，在有用户使用通行码时，也有用户可能还在打开小程序（B服务、C服务）之类的功能，所以我们采用混合场景分配比列压测尽可能接近真实，但又不是所有场景都考虑，因为我们关注的指标在这个混合场景下可以得出一部分，还有该场景是使用最多、最容易产生高并发的，我们没有那么多假设去测试所有场景。   图1 混合压测场景     但是就只采用提到的混合场景，我们能得到gateway和系统事务处理能力TPS的指标及资源利用率，其他有些服务又不能压测到，对于微服务架构来说，某些服务压测到了（在服务器分配给这个服务的资源下，该服务可以处理的请求及服务器资源利用率），有些服务没压测到（云服务器有分配资源，但请求没到这个服务或者很少的请求，那也就不清楚这个服务下的资源利用率，能承载多少请求），所以还得再添加一个简单的测试方案：针对各个服务再压一次，选择一个常用的接口，去观察各个服务能正常处理的请求、资源利用率。这里设计是最简单的：选择一个常用接口去测，单压服务最完善的，应该是每个接口都测试下，然后统计比较得出压测结果，但实际上在项目上实施比较难：接口太多，接口使用概率不同。   图2 单压服务的可压接口     3. 系统/场景/接口的用户数据——表示系统一般有多少用户量，有多少用户数据，要压测的对象设置多大并发数。     对于要测试的对象，我们得知道访问量或者范围，我们初次上线的系统没有历史数 据做参考，就需要从其他渠道分析得出访问量，比如这个系统给哪些群体使用，这些群体范围有多大，大体做一个评估。我们系统主要是写字楼里员工使用，目前有两栋楼，预估每栋楼有2400个员工，员工使用通行码调度电梯高峰期10分钟，而每个员工使用二维码调度电梯时会有排队处理，假设每个员工间间隔1秒；从这些数据算出使用系统的并发量为8/s。以后使用这个系统的地产公司有8栋楼时，并发量就提高到32。如果32还能承受，那再大一些是否还正常运行，也可以检验的。 三、 性能测试环境数据准备     在明确了测试指标、测试场景和用户数据，我们要开始造数据了，从上面的分析中我们知道，员工数据范围在4800~19200，那数据库里涉及到的相关表数据就要满足这个范围。     一般情况下，我们也不是一开始来就直接造4800员工数据和设置用户并发量8及19200和32。从（4800，8）到（19200，32）我们可以采用分阶梯式压测，比如先压（4800，8）一段时间，看满足需求后再慢慢按照楼栋情况（2400，4）整倍的方式加压，最后在（19200，32）上加压一段时间。根据这个压测的方式，我们就涉及到一些造数据的方法和步骤，我们这个压测场景涉及到的几个接口是获取数据，所需的数据是几个表组合起来的，我们可以采用追加的方式利用SQL脚本把数据插入数据库表里。     而本次我们可以尝试一开始直接压预估范围内的最大并发和准备用户数据，毕竟这个数据也不大，如果这个压测结果还比较理想，我们可以按照一定策略往上加并发量；如果压测结果不理想我们再采用往下减并发量压。     一些场景涉及到的表格很多而且比较复杂，通过纯粹的SQL脚本插入数据时要保证链路上的数据的完整性和正确性比较难时，也可以采用其他造数据的方法。     我们做性能测试时好多数据是通过“造”出来的，所以肯定存在脏数据，所以最好不要在线上压测，而是配置一个和线上环境一样的临时干净环境，压测后全部压测数据清理掉和资源释放掉。（这次我们的项目是新产品，没有其他用户，所以直接采用线上环境压测，再清理数据）。     举例压测的场景没有第三方系统，如果有第三方系统，在这个压测环境里还需要mock或者fake掉第三方。 四、 性能测试执行     对于性能测试，我们知道了要哪些指标，准备好了测试接口，拟定了什么方式测试（混合压、单压）以及怎么造数据，那下一步我们要选择支持性能测试的工具编写脚本了。   图3 某个接口压测执行策略     在性能测试领域中，工具框架也是多种，比如JMeter、Gatling、Locust 、K6等，每种工具有自己的优缺点，在选择工具框架时要根据执行策略和项目的情况来选择适合的。     我对要测试的这个系统最开始选择了JMeter作为压测工具，因为有几点优势：     1. 上手快（有图形化界面配合写压测脚本，本人也熟悉Java代码编写）     2. 运行环境简单（有Java运行环境JVM就行，下载JMeter就可以跑脚本了）     3. 可以执行混合压测的模式（可以配置每个场景、接口的并发比例）     4. 可以参数化命令运行（执行的并发量、持续时间可以参数运行，不用脚本里修改， jmeter -n -t ****/KerrySmart_Own.jmx -l ****/report.csv -e -o ****/report_own_qr_32 -JthreadNum=32 -JramupTime=60 -JramupStep=4 -JholdTime=300 -JhostUrl=******）     5. 报告可以直接看出TPS、响应时间、成功率     从上面几点就可得出利用JMeter能满足目前的压测，而且并发量不大，JMeter（JMeter有个很明显缺点，就是不能支持大并发量，几百个并发就特别消耗压测机的性能）也可支撑。     后来我又用了Gatling，Gatling也具有上述的功能，同时对于这次项目要压测的方案（混合、单压）可以在一套代码里很好的管理，只要执行测试时选择要执行的类就行了（比如 ./gradlew gatlingRun-MixedScenario.MixedTestSimu -DuserCount=64 -DstartUserCount=8 -DrampDuringTime=30 -DduringTime=300 -DhostUrl='******'）。JMeter就不行，如果要执行这个方案，用JMeter需要写两个脚本，而且单压测不同接口时还得再配置。     五、 性能测试结果分析     性能测试完之后，或者性能测试过程中都需要对测试结果进行分析，我们常用响应时间（95p，99p，max及结合详细图来看）、KO、QPS之类的来分析压测结果。比如从图4 和图5（上述图3中的服务接口压测结果）中看出，我们压测到这个情况下，可以不用再压测了，并发量72在这种情况下的QPS为68左右就是系统还能正常处理的极限了。再从资源使用情况看，资源利用率也很大了（2核CPU使用率很高了），针对这种情况，如果要提高QPS，有种解决方案就是增加CPU。     当然对于压测结果，也有很多其他情况，比如：     1. 出现KO率（各种timeout）但是服务器资源利用率又不高，就有可能和网络限制（gateway的带宽、服务的带宽、网络延迟等）有关了。     2. 没出现KO率/出现KO，响应时间随着并发量增大，有可能和查询数据库有关，也有可能和代码有关，这些都需要看具体情况分析，再做相应的优化。   图4 并发72的     图5 并发80的      图6 并发80的       图7 几次不同并发压测时资源使用情况 六、 性能调优     关于性能调优，具体调优情况需要根据测试结果分析做方案。这里就不具体记录了。         系统调优遵循的规则如下： 中间件调优：线程池、数据库连接池、JVM。 数据库调优：效率低下SQL、死锁和锁等待、缓存命中率，进程和会话参数。 应用调优：方法耗时、算法、同步和异步、缓存、缓冲。 系统资源：一般情况下，系统资源（例如CPU等）大部分是由应用和参数设置不合理导致的，并非系统资源真的不够”用”。      写在最后     这只是我记录的一次在项目上的性能测试，不同项目对性能的要求可能会不同，那么性能目的也可能不一样，具体实施的方案也就会不太一样；但要做性能测试，从开始到最后我们的策略基本上是类同的。           回复转发