在高负载压力下支付宝是如何做性能测试的

发表于:2014-06-13来源:infoq作者:付丽华 孙玉星点击数: 标签:支付宝
一、性能测试支付宝场景介绍 2013年双11过程当中,促销开启的第一分钟内支付宝的交易总额就突破了一亿元,短时间内大量用户涌入的情况下,如何保证用户的支付顺畅,是对支

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

  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数据。

原文转自:http://www.infoq.com/cn/articles/performance-test-of-zhifubao