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

　　解决方案：

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

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

　　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是否分库分表，需要保证数据分布的均衡性。一般考虑到线下准备数据的时长，一般性能测试要求和线上的数据保持一个数量级。