一、性能测试支付宝场景介绍
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.
