支付宝的性能测试

一、性能测试支付宝场景介绍

　　2013年双11过程当中，促销开启的第一分钟内支付宝的交易总额就突破了一亿元，短时间内大量用户涌入的情况下，如何保证用户的支付顺畅，是对支付宝应用系统的一个极大的挑战。

　　支付宝的性能测试场景分为性能基线测试，项目性能测试。

　　任意一笔交易过来，我们都需要对交易进行风险扫描，对于有可能是账户盗用的交易，我们会把这笔支付直接拒绝掉，或者通过手机校验码等方式进行风险释放。

　　我们有一个老的扫描平台A，现在需要构建一个新的扫描平台B，对A中关键技术进行升级，并增加额外的功能。扫描的策略是存储在DB中的，需要通过发布来更新到应用服务器的内存中。

　　二、性能测试需求分析和方案制定

　　a. 需求挖掘

　　1),查看业务方的显性需求。业务方给到的需求为平台B的分析性能要优于平台A的性能。除此之外无其它的需求。

　　2),挖掘隐性需求.了解业务架构，了解业务流程。为了保证扫描的性能，大量的存储类的需求被设计为异步处理，但是结果类的扫描需要使用到前面落地的数据，那么在系统正常运行时是否会存在落地数据读取不到的问题，在存储抖动时是否会导致后续的分析扫描全部失效?

　　首先我们领测国际通过运维监控平台拿到平台A的分析性能，RT<130ms, TPS>35.

　　基于以上的需求挖掘，我们确认的性能测试场景为

　　扫描性能场景。(单场景)

　　发布性能场景。(单场景)

　　扫描过程中发布性能场景。(混合场景)

　　b. 技术方案

　　1).评估我们的系统架构，系统调到链路，定位可能存在问题的瓶颈点。

　　2).掌握详细技术实现方案，了解具体技术方案可能存在的性能问题。

　　比如我们是否使用到了脚本动态编译，是Java脚本还是groovy脚本。是否使用到了线程池等异步处理，系统幂等性是如何控制的，数据结构是如何存储与读取的，是决策树还是图型结构。

　　3).了解系统环境的差异，比如服务器位数、CPU、内存的差异，JDK版本及位数的差异。

　　基于以上的技术方案，我们确认了上述3个性能测试场景可能存在的性能问题

　　1. 扫描性能场景

　　技术方案为扫描引擎drools2升级到了drools5.

　　性能关注点为请求扫描RT，TPS是否满足我们的需求;JVM Old区内存溢出，Old区内存泄露;GC 频率过高。CPU使用率，load.

　　2. 发布性能场景

　　技术方案为规则DB捞取->规则加载->规则引擎切换->规则脚本编译。

　　性能关注点为CPU使用率,load。JVM Perm区内存溢出，Perm区内存泄露，GC 频率过高。GC 暂停应用时间。

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

　　性能关注点为请求扫描RT，TPS。规则发布耗时，CPU使用率，load, JVM GC频率。

　　c. 性能测试方案制订

　　分布式压测，参数自动化，使用单元测试脚本，接口测试脚本，jmeter脚本等进行压测。

　　性能结果收集及统计。

　　性能测试通过标准。

　　基于以上的分析

　　1. 扫描性能场景

　　性能测试方案：

　　使用jmeter 脚本进行分布式压测，一台master, 三台slaver. 参数自动构建，使用高斯定时器模拟真实场景。

　　使用jmeter 收集分析性能数据，使用nmon收集服务器性能数据，使用jconsole收集JVM数据。

　　通过标准:

　　RT<130ms, TPS>35.

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

　　CPU<70%， load < core*1.5。

　　2. 发布性能场景

　　性能测试方案：

　　发布时间间隔时间从1min调整为3s, 更快的暴露问题。

　　使用单元测试类推送发布消息。

　　服务器shell 脚本收集发布模块性能数据。

　　使用nmon收集服务器性能数据。

　　使用jconsole收集JVM数据。

　　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住，造成大量超时

　　解决方案：

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