支付宝性能测试案例分析，成功入职阿里月薪45K

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

通过标准：

JVM Perm 区内无内存泄露，无内存溢出。GC时间间隔10min，暂停应用时间200ms. 发布时间30S CPU70%， load core*1.5。 3.扫描过程中发布性能场景 性能测试方案： 使

JVM Perm 区内无内存泄露，无内存溢出。GC时间间隔>10min，暂停应用时间<200ms.

发布时间<30S

CPU<70%， load < core*1.5。

3.扫描过程中发布性能场景

性能测试方案：

使用jmeter脚本进行分布式压测，同时提交发布请求进行发布。

同时使用扫描性能场景和发布性能场景收集数据功能。

通过标准：

RT < 扫描性能场景结果RT * 110%.

TPS > 扫描性能场景结果TPS * 90%.

发布时间 < 40s。

d. 发现的问题

1. 扫描性能场景

AVG RT = 473ms， CMS GC = 90ms, 应用暂停时间 = 1s, 因此测试未通过。

问题定位：

dump内存，使用ibm memory analyzer 分析。

确认cms gc的原因为drools引擎的finalize方法。Finzlize方法不能正确的释放对象的引用关系，导致引用关系一直存在，无法释放。

调优方案：

根据drools的升级文档，升级drools引擎后解决此问题

2. 发布性能场景

CMS GC 回收失败，内存无法被释放，应用宕机。

问题定位：

GC回收比例为默认值68%，OLD区内存1024M，那么回收的临界值为1024*0.68=696.32M。系统的JVM内存占用为500M，扫描策略相关的内存为120M，在切换的过程中，依赖额外的120M，因此只有在可用内存大于740M时才能正常回收。

解决方案：

调整JVM参数，扩大GC回收比例。

后续技术方案改造，使用增量发布解决此问题。

3. 扫描过程中发布性能场景

问题定位：

扫描平台发布流程，当首次请求进来时执行脚本动态编译过程，由于脚本较多，因此所有脚本的动态编译时间较长，在此过程中，进来的所有请求都会被hand住，造成大量超时

解决方案：

把脚本的动态编译提前到首次请求调用进来之前，编译通过后再切换扫描引擎，保证首次请求进来前一切准备就绪。

三：性能测试的执行和结果收集

3.1性能测试的执行

性能测试的执行需要具备以下几个条件：施压工具,测试环境以及对测试结果的收集工具。

3.1.1 施压工具

我们先来说说施压工具，支付宝使用的主流施压工具是开源工具Apache JMeter，支持很多类型的性能测试：

Web - HTTP, HTTPS

SOAP

Database via JDBC

LDAP

JMS

任何用java语言编写的接口，都可二次开发并调用。

支付宝大部分接口是webservice接口，基于soap协议，且都是java开发，所以使用jmeter非常方便，即使jemter工具本身没有自带支持的协议，也可以通过开发插件的方式支持。

3.1.2测试环境

测试环境包括被压机和施压机环境，需要进行硬件配置和软件版本确认，保证系统干净，无其他进程干扰，最好能提前监控半小时到1小时，确认系统各项指标都无异常。

另外除了被压机和施压机，有可能应用系统还依赖其他的系统，所以我们需要明确服务器的数量和架构，1是方便我们分析压力的流程，帮助后面定位和分析瓶颈，2是由于我们线下搭建的环境越接近线上，测试结果越准确。但是通常由于测试资源紧张或者需要依赖外围，例如银行的环境，就会比较麻烦，通常我们会选择适当的进行环境mock。当然，Mock的时候尽量和真实环境保持一致，举个简单的例子，如果支付宝端系统和银行进行通信，线上银行的平均处理时间为100ms，那么如果我们在线下性能测试时需要mock银行的返回，需要加入100ms延迟，这样才能比较接近真实的环境。

另外除了测试环境，还有依赖的测试数据也需要重点关注，数据需要关注总量和类型，例如支付宝做交易时，db中流水万级和亿级的性能肯定是不一样的;还有db是否分库分表，需要保证数据分布的均衡性。一般考虑到线下准备数据的时长，一般性能测试要求和线上的数据保持一个数量级。

3.1.3 测试结果收集工具

测试结果收集主要包括以下几个指标：

响应时间、tps、错误率、cpu、load、IO、系统内存、jvm(java虚拟内存)。

其中响应时间、tps和业务错误率通过jemter可以收集。

Cpu、load、io和系统内存可以通过nmon或linux自带命令的方式来监控。

Jvm可以通过jdk自带的jconsole或者jvisualvm来监控。

总体来说，监控了这些指标，对系统的性能就有了掌握，同样这样指标也可以反馈系统的瓶颈所在。

四.性能测试瓶颈挖掘与分析

我们在上面一章中拿到性能测试结果，这么多数据，怎么去分析系统的瓶颈在哪里呢，一般是按照这样的思路，先看业务指标：响应时间、业务错误率、和tps是否满足目标。

如果其中有一个有异常，可以先排除施压机和外围依赖系统是否有瓶颈，如果没有，关注网络、db的性能和连接数，最后关注系统本身的指标：

硬件：磁盘是否写满、内存是否够用、cpu的利用率、平均load值

软件：操作系统版本、jdk版本、jboss容器以及应用依赖的其他软件版本

Jvm内存管理和回收是否合理

应用程序本身代码

先看下图：是一般性能测试环境部署图

我们在定位的时候，可按照标注中的1、2、3数字依次进行排查，先排查施压机是否有瓶颈、接着看后端依赖系统、db、网络等，最后看被压机本身，例如响应时间逐渐变慢，一般来说是外围依赖的系统出现的瓶颈导致整体响应变慢。

下面针对应用系统本身做下详细的分析，针对常见问题举1~2个例子：

4.1 应用系统本身的瓶颈

1. 应用系统负载分析：

服务器负载瓶颈经常表现为，服务器受到的并发压力比较低的情况下，服务器的资源使用率比预期要高，甚至高很多。导致服务器处理能力严重下降，最终有可能导致服务器宕机。实际性能测试工作中，经常会用以下三类资源指标判定是否存在服务器负载瓶颈：

1.CPU使用率

2,内存使用率

3.Load

一般cup的使用率应低于50%，如果过高有可能程序的算法耗费太多cpu，或者某些代码块进行不合理的占用。Load值尽量保持在cpuS+2 或者cpuS*2，其中cpu和load一般与并发数成正比(如下图)

内存可以通过2种方式来查看：

1. 当vmstat命令输出的si和so值显示为非0值，则表示剩余可支配的物理内存已经严重不足，需要通过与磁盘交换内容来保持系统的稳定;由于磁盘处理的速度远远小于内存，此时就会出现严重的性能下降;si和so的值越大，表示性能瓶颈越严重。

2. 用工具监控内存的使用情况，如果出现下图的增长趋势(used曲线呈线性增长)，有可能系统内存占满的情况：

如果出现内存占用一直上升的趋势，有可能系统一直在创建新的线程，旧的线程没有销毁;或者应用申请了堆外内存，一直没有回收导致内存一直增长。

4.2 Jvm瓶颈分析

4.2.1Gc频率分析

对于java应用来说，过高的GC频率也会在很大程度上降低应用的性能。即使采用了并发收集的策略，GC产生的停顿时间积累起来也是不可忽略的，特别是出现cmsgc失败，导致fullgc时的场景。下面举几个例子进行说明：

1. Cmsgc频率过高，当在一段较短的时间区间内，cmsGC值超出预料的大，那么说明该JAVA应用在处理对象的策略上存在着一些问题，即过多过快地创建了长寿命周期的对象，是需要改进的。或者old区大小分配或者回收比例设置得不合理，导致cms频繁触发，下面看一张gc监控图(蓝色线代表cmsgc)

由图看出：cmsGC非常频繁，后经分析是因为jvm参数-XX:CMSInitiatingOccupancyFraction设置为15，比例太小导致cms比较频繁，这样可以扩大cmsgc占old区的比例，降低cms频率注。

调优后的图如下：

2. fullgc频繁触发

当采用cms并发回收算法，当cmsgc回收失败时会导致fullgc：

由上图可以看出fullgc的耗时非常长，在6~7s左右，这样会严重影响应用的响应时间。经分析是因为cms比例过大，回收频率较慢导致，调优方式：调小cms的回

由上图可以看出fullgc的耗时非常长，在6~7s左右，这样会严重影响应用的响应时间。经分析是因为cms比例过大，回收频率较慢导致，调优方式：调小cms的回比例，尽早触发cmsgc，避免触发fullgc。调优后回收情况如下

可以看出cmsgc时间缩短了很多,优化后可以大大提高。从上面2个例子看出cms比例不是绝对的，需要根据应用的具体情况来看，比如应用创建的对象存活周期长，且对象较大，可以适当提高cms的回收比例。

3. 疑似内存泄露，先看下图

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
如应用创建的对象存活周期长，且对象较大，可以适当提高cms的回收比例。

3. 疑似内存泄露，先看下图

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-iNE2FYhU-1713560452688)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！